Prepare GitLab application for ratelimiting transition to Redis Cluster

How the webservice interacts with redis-ratelimiting

1. Gitlab::ApplicationRateLimiter::BaseStrategy uses increment and read which are same-key pipelined operations. This means there are no cross-slot operations and can be transited into a Redis Cluster without issues.

   • https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/application_rate_limiter/increment_per_action.rb
   • https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/application_rate_limiter/increment_per_actioned_resource.rb

2. Rack::Attack using Gitlab::RackAttack::InstrumentedCacheStore as cache for increment, write, read.

   • reset! method in Rack::Attack::Cache calls delete_matched which performs a scan. However, Rack::Attack.reset! is typically used for test suite isolation (https://github.com/rack/rack-attack#test-case-isolation). This means more elaborate spec helpers but it should not affect our application in gstg/gprd. This is fine since Redis::Cluster broadcast flushdb to all master nodes.

Changes required

No application level changes are required other than configurations in helm charts.

Updates

We will either proceed using gitlab-org/gitlab!106123 (merged) or #2064 (closed) (and test in pre by directly updating config in gitlab-com).