Code Climate complains about the complexity of this method. Here we try to reduce it by using private methods that encapsulate some details that are not required to understand the implementation of the main method.
* attempt to improve semantics for legibility
* Attempt to improve legibility by simplifying
* Make it more clear that we're calling procs/blocks here
* Enable rubocop Style/BlockDelimiters cop
* Prefer 'request' over 'req' abbreviation for legibility/clarity
* Instances of Track named 'track' not 'tracker'
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
I need to filter requests on a period I need to get dynamically out of
information I have in the requests. Currently, I can work out the limit,
as it can be a `Proc`, however I can't do that with the period.
This PR adds support for that. Tried to do it in a way that doesn't
brake backwards compatibility, as periods are coerced to numbers during
`Rack::Throttle` initialization.
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.
