Handle 429 responses

[JWCook]

If client-side rate-limiting doesn't match the server-side rate-limiting (or the server doesn't behave as documented/expected), it may still be possible to get a 429 Too Many Requests response.

This could potentially be handled by this library. Or would it be better just to let the user handle this with standard retry behavior, e.g. with urllib3.util.Retry?

[Avasam]

I am not using this library yet, but special case here: The api I call (speedrun.com) returns "420" (with the message "chill out") rather than the standard 429. It also randomly fails with 502 or 504 when it's under some heavy load.
For now I just retry with a random delay to try and spread out the calls.

I think it would be interesting if hitting 429 would "fill" the bucket and if I could specify other response code to act this way as well. But it's far from a necessity.

[JWCook]

Yeah, I think just filling the bucket after getting a rate-limiting response makes the most sense. That would at least reduce the number of retries needed. Adding the actual retry logic to this library probably isn't necessary since it's easy enough to set up yourself.

Here's an example in an API client I maintain that takes basic retry settings as session args: https://github.com/niconoe/pyinaturalist/blob/main/pyinaturalist/session.py#L49-L132

Made a separate issue for other rate-limit status codes (#34).

[JWCook]

This and #34 are now in v0.3.0.