refactor: rewrite http ratelimiting to be dynamic

[EmmmaTech]

Summary

This PR rewrites http ratelimiting to be more dynamic. Closes #663.

I'm not sure whether to declare this PR as feature or breaking for the changelog entry, so please let me know which one it should be.

Checklist

• [ ] If code changes were made, then they have been tested
  • [ ] I have updated the documentation to reflect the changes
  • [ ] I have formatted the code properly by running task lint
  • [x] I have type-checked the code by running task pyright
• [ ] This PR fixes an issue
• [ ] This PR adds something new (e.g. new method or parameters)
• [x] This PR is a breaking change (e.g. methods or parameters removed/renamed)
• [ ] This PR is not a code change (e.g. documentation, README, ...)

[EmmmaTech]

Is there a possible race condition here given the original lock and then the one used in subsequent requests are going to be seperate Lock objects? Just given if there is a bucket from within the request it will generate a new lock object and use that for subsequent requests from what I can see

That could be a possibility, yeah.