limiter: Integrate adaptive limit to pack-objects limiter

For #5614 (closed)

This MR integrates the adaptive limit to the pack-objects limiter of the Gitaly server. It introduces some new configurations for pack-objects limiting. When the Gitaly server starts, it creates an adaptive calculator. The calculator adjusts the adaptive limit which is already integrated into the concurrency limit in prior commits.

To enable the adaptive limiter, the operator needs to set pack_objects_limiting.adaptive config to true and corresponding limits located at the same location.

What happens after this MR is merged

Nothing. To enable the adaptiveness of pack_objects limiting, we need to add the following settings. On GitLab.com, we'll gradually roll this config out node by node.

[pack_objects_limiting]
// Backward compatible with the static one
max_concurrency = 15
adaptive = true
initial_limit = 15
max_limit = 100
min_limit = 1
max_queue_length = 15
max_queue_wait = "30s"

Manual testing scenarios

• ✅ Pack-objects' adaptive limiting is disabled

[pack_objects_limiting]
max_concurrency = 2
max_queue_length = 1
max_queue_wait = "600s"

• ✅ Pack-objects limit climbs up gradually until reaching the max limit.
  • ✅ The limit gradually increases after each calibration (30 seconds).
  • ✅ The limiting works as expected. There are at most N concurrent pulls matching the current limit.
  • ✅ When the current limit is reached, requests wait in the queue.
  • ✅ When the limit increases, the next waiting request is unlocked.
  • ✅ When the request queue is full, the next request is rejected.

[pack_objects_limiting]
max_queue_length = 1
max_queue_wait = "600s"
adaptive=true
min_limit = 1
initial_limit = 1
max_limit = 4

• ✅ Pack-objects limit climbs up gradually until reaching a backoff event.
  • ✅ The limit gradually increases after each calibration (30 seconds).
  • ✅ The limiting works as expected. There are at most N concurrent pulls matching the current limit.
  • ✅ When there is a backoff event, the limit decreases by 50%.
  • ✅ After the limit decreases, ongoing requests keep going and waiting requests continue to wait.
  • ✅ After the "leftover" requests are done and there is one slot, the next request is unlocked.
  • ✅ The limit increases by one if the next calibration is positive.
  • ✅ When there are multiple consecutive events, the limit drops to the min limit.

[pack_objects_limiting]
max_queue_length = 1
max_queue_wait = "600s"
adaptive=true
min_limit = 1
initial_limit = 1
max_limit = 4