We have several API rate limiting tests that check various time intervals. One checked against a number of failed attempts per hour. One checked against attempts per minute. And one checked against attempts per second. The per second test often failed in CI under load. This was checking that 3 login attempts were allowed but a 4th would fail. If there was enough delay, this 4th would often fail as well. We now staple the timestamp so it doesn't change. This requires a spy on an internal `_get_window()` function from `djblets.auth.ratelimit`, but as all this is internal, that should be fine. Now, regardless of actual clock changes, the time window should not change, and therefore the test should not fail under load. However, this uncovered that our actual rate limit logic encountered problems when the logic operated over a 1 second boundary change. There were repeated calls to `_get_window()`, which in turn called `time.time()`. The first set of calls was used for the cache key, and the second set for a calculation. If the second changed in-between these, there'd be a mismatch. It probably wasn't very harmful in practice, but was worth fixing. The rate limiting code now fetches the time and window up-front, once, before any cache keys or calculations. Unit tests were added to check for this.