Improve tracking of requests in rate limiter

What does this MR do and why?

This follows Rack::Attack's strategy in counting requests in Redis. This ensures that we don't end up in a state where the counter never expires and the user is always blocked. This could happen if the process gets terminated between the INCR and EXPIRE calls.

With the new approach, the expiry is less important and is only used so that we don't store useless keys in Redis.

How to set up and validate locally

1. Enable the rate_limiter_safe_increment feature flag.
2. This can be easily tested in the console with Gitlab::ApplicationRateLimiter.throttled?

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

• I have evaluated the MR acceptance checklist for this MR.

Related to #285352 (closed)