Simplify RateLimiter to avoid handling expiration in code

[aduth]

🛠 Summary of changes

Updates RateLimiter to avoid handling expiration through code logic. Since we use Redis' built-in key expiration, we can infer expiration based on the absence of a key in the store.

Draft: Clarify assumptions.

📜 Testing Plan

TBD

[aduth]

One potential issue here is that we rely on a local expiration value when incrementing multiple times on the same instance, to avoid calling to Redis (related failing spec).

We could keep some of the local expiration tracking for when incrementing while still removing the Redis GETEX operation, but I'm also wondering if this is really a scenario we encounter much in real usage, vs. contrived in specs. In typical usage, we're only ever incrementing once.

[aduth]

Going to close this for now until some of the other rate-limit related changes settle in this class, specifically those in #10982.