Acceptance tests coverage

[grzuy]

Continue what started in #269, by writing more test cases that make assertions specifically about the behavior the user should expect the gem to provide to them, without any assertions about the internals or implementation details.

[...] testing with respect to user needs, requirements [...] conducted to determine whether a system satisfies the acceptance criteria.

from https://en.wikipedia.org/wiki/Acceptance_testing

---

User-facing features:

• blocklist (Adds acceptance-oriented tests #269)
• safelist (Adds acceptance-oriented tests #269)
• throttle (Adds acceptance-oriented tests #269)
• allow2ban (Acceptance test allow2ban #304)
• fail2ban (Acceptance test fail2ban #303)
• tracks (Acceptance test Rack::Attack#track #294)
• custom throttled response (Acceptance test ability to customize blocked/throttled responses #298)
• custom blocked response (Acceptance test ability to customize blocked/throttled responses #298)
• cache store config for throttle (Acceptance test cache store config for throttle without Rails #297)
• cache store config for allow2ban (Acceptance test store config for allow2ban/fail2ban #305)
• cache store config for fail2ban (Acceptance test store config for allow2ban/fail2ban #305)
• cache store config when Rails present (Acceptance test cache store config when Rails is present #307)
• throttle's Retry-After HTTP response header (Acceptance test throttle Retry-After header #306)
• throttle's limit argument as a proc (Acceptance test throttle dynamic arguments #309)
• throttle's period argument as a proc (Acceptance test throttle dynamic arguments #309)
• ability to extend request object (Acceptance test ability to extend the request object #310)
• blocklisted_response access to match data (Acceptance test access to match data in custom responses #311)
• throttled_response access to match_data (Acceptance test access to match data in custom responses #311)
• notifications (Acceptance test ability to subscribe to notifications #319)