feat(Rest): improve global rate limit and invalid request tracking

[ckohen]

Please describe the changes this PR makes and why it should be merged:

Ported from discordjs/discord.js#4711
The logic is all taken pretty much directly. This is the start of a series of PRs to catch up the REST module to discord.js v13s built-in REST implementation.

Status and versioning classification:

• I know how to update typings and have done so, or typings don't need updating
• This PR changes the library's interface (methods or parameters added)
• This PR includes breaking changes (methods removed or renamed, parameters moved or removed)

[codecov]

Codecov Report

Merging #51 (674fdd7) into main (9eb6afb) will decrease coverage by 1.15%.
The diff coverage is 82.90%.

❗ Current head 674fdd7 differs from pull request most recent head c18f541. Consider uploading reports for the commit c18f541 to get more accurate results

@@            Coverage Diff             @@
##             main      #51      +/-   ##
==========================================
- Coverage   89.98%   88.82%   -1.16%     
==========================================
  Files           8        8              
  Lines        1108     1342     +234     
  Branches      109      142      +33     
==========================================
+ Hits          997     1192     +195     
- Misses          3        9       +6     
- Partials      108      141      +33     

Impacted Files	Coverage Δ
packages/rest/src/lib/utils/utils.ts	72.97% <70.83%> (-3.96%)	⬇️
...ackages/rest/src/lib/handlers/SequentialHandler.ts	82.83% <81.06%> (-1.29%)	⬇️
packages/rest/src/lib/RequestManager.ts	93.89% <92.30%> (+0.20%)	⬆️
packages/rest/src/lib/REST.ts	96.17% <100.00%> (+0.59%)	⬆️
packages/rest/src/lib/utils/constants.ts	100.00% <100.00%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 9eb6afb...c18f541. Read the comment docs.

[ckohen]

Breaking Change in the last commit:
Sublimit requests will 429 on every request as there is no effective way to ensure the sublimit is not hit other than stalling the entire bucket for the entire duration of the sublimit

Note: they are retried after the timeout still

Edit: this will be hardcoded around for the only known sublimit in the next commit

Stale

[ckohen]

Okay, significant refactor to sublimit handling, here's how it should work now:

• Normal requests get added to the normal queue
• Potentially sublimited requests get added to the normal queue when there is no sublimit queue
• If a sublimit is actually hit, a sublimit queue is constructed
• When a sublimit queue exists, every request is checked (retroactively too) for whether it is sublimited before being sent out
• If the request is sublimited:
  • Retroactively remove the request from the normal queue if it existed there
  • Wait for the sublimit queue instead
• Otherwise wait for the standard queue and if the sublimit queue is being processed, wait for that
• Remove the sublimit queue when it has no more requests pending

[ckohen]

Test have been added to cover everything that has changed!

Stale

[ckohen]

I totally forgot I still had this PR open 🤦 , addressed changes and rebased.

Stale

Stale

Stale