Rate Limiting Handling

[z64]

Implements a mutex around API#request that protects against making rate limited requests.

This works by:

• Caches the last response we received from the API
• Checks headers for how many requests we have left (:x_rate_limit_remaining)
• If we have no requests remaining, and we haven't passed the reset timestamp (x_rate_limit_reset), sleep for x_rate_limit_reset_remaining milliseconds
• This is all done inside of a Mutex#synchronize block and is therefore thread-safe.

Todo:

• Squash

---

Example raw rate limit headers:

x-rate-limit-limit →1s
x-rate-limit-remaining →0
x-rate-limit-reset →2017-07-26T14:39:58.2291610Z
x-rate-limit-reset-remaining →206

[z64]

To clarify this defaulting to -1:

last_header(:x_rate_limit_remaining)&.to_i returns [Integer, nil] which would fail the subsequent #zero? check in #will_be_rate_limited?. I opted just to return -1 as it isn't zero (it's unknown until we make our first request).

In contrast, if we default to zero, then #will_be_rate_limited? may return true on the first request and sleep for 0 seconds. This isn't a big deal either, but if we implement something like rate limit logging later, it may look pretty confusing. 1 may also be an acceptable default for this method, but it isn't true (we didn't get that from the API) ; so I think this justifies -1 as a special case.