This is allows access to the same time that the cache uses for the count. This can be important for clients that want to provide rate limit information for well-behaved clients
Fixes#69.
There was a race condition when `Time.now.to_i` changes between when
`epoch_time` is computed in line 18, and the cache request is made (and
the `key` is expired).
I.e., a throttle check starts at t0, but doesn’t reach the cache until
t1, the cache will have expired the throttle count. The request will
likely be allowed, even if the request exceeded the limit.
This has the effect of keeping keys in cache about 1 second longer than
strictly necessary. But the extra cache space seems like a good
trade-off for correct throttling.
Throttles use a cache key with a timestamp (Time.now.to_i/period), so a
new cache key is used for each period.
No longer set an explicit expiry on each cache key (though it may
inherit a default expiry from the cache store).
Also, set env['rack.attack.throttle_data'] with info about incremented
(but not necessarily exceeded) throttles.
