Bump gitlab-labkit to 2.0.0 for atomic Lua rate-limit script

Max Woolfrequested to merge
bump-gitlab-labkit-to-v2 into master

What this MR does

Bumps gitlab-labkit from 1.19.0 to 2.0.0 to pick up gitlab-org/ruby/gems/labkit-ruby!291 (merged) — a single atomic Lua script replacing the pipelined INCR+EXPIRE in Labkit::RateLimit::Evaluator.

This is the first of two stages in adopting labkit 2.0:

  • Stage 1 (this MR): Gem bump only. The Gitlab::ApplicationRateLimiter labkit adapter is forward-compatible with the new cost: keyword default of 1, so cohorts 1–3 (already routed through labkit under shadow/enforce flags) pick up the atomic script transparently.
  • Stage 2 (separate MR): Wire cohort 5 (IncrementResourceUsagePerAction, gitlab-com/gl-infra/production-engineering#28812 (closed)) through the new cost: API.

Why this is safe to deploy

Once merged, every labkit-routed cohort in production immediately gets the atomic script. The behavior change is correctness-improving (atomic vs split, self-healing TTL=-1 keys) and there is no consumer-facing API surface change for this adapter; v2.0 was bumped solely because Result::Info#count changed from Integer to Float, and the adapter only reads .exceeded? / .error?. git grep result.info.count returns zero hits in this repo.

There is no opt-in feature flag because the swap is internal to Labkit::RateLimit::Evaluator. The existing per-cohort shadow/enforce flags continue to gate which keys route through labkit at all.

Test plan

  • spec/lib/gitlab/application_rate_limiter/labkit_adapter_spec.rb — 36/36 passing
  • ee/spec/lib/ee/gitlab/application_rate_limiter/labkit_adapter/supported_rate_limits_spec.rb — 6/6 passing
  • spec/lib/gitlab/application_rate_limiter_spec.rb — 56/56 passing

Related

Merge request reports