configurable max wait time for rate limits

Summary

A way for the library to short-circuit requests that will be waiting for rate limits for too long

What is the feature request for?

The core library

The Problem

Currently when doing a http call there is no way to know when exactly it will be executed due to rate limits. While in some cases a delay of a few seconds is not a big deal, other limits (most notably are guild wide limits of up to 24h hours on roles and emoji) are so long that it is not reasonable to wait for them. As this creates a terrible end user experience (bot is not doing anything, did it break?)

The Ideal Solution

The library is already rate limit aware, it would be ideal if it could emit an exception if the wait time is (or will be) longer then a configurable timeframe (defaulting to infinite to not break backwards compatibility). If possible it would be neat if the exception contained some info on the min expected wait time for the limit to clear. More specifically:

• If when making the function call the lib is already waiting on a rate limit to pass that is longer then the configured timeframe it would throw an exception
• If the library tries to execute the call but gets rate limited (and requeue's the request) for a timeframe longer then the configured timeframe it throws the exception
• If there are rate limits active but the request remains in queue due to other requests queued up before it for longer then the configured timeframe it throws the exception (for consistency and easy of use, prevents having to wrap it in a wait_for by the consumer as well)

The Current Solution

Wrap the call in a wait_for call. This has many downsides:

• needs to be done in every single place you interact with the api
• discord can add new rate limits at any time if they see the need for it, thus you would need to wrap absolutely everything to be sure your bot always responds in a timely manner to commands
• wait_for doesn't short-circuit. It either completes when the rest call does, or when the timeout is over. Thus requiring you to wait the entire max time each time you are rate limited for an extended time.

Additional Context

No response