limiter: Add adaptive limit to the concurrency limiter (second attempt)

For #5523 (closed)

This MR is the re-implementation of !6183 (merged), which was reverted due to a memory-leak incident.

Similar to the prior MR, this MR adds support to the adaptive limit to the concurrency limiter. This addition doesn't enable the adaptive calculator, which is responsible for adjusting the limit up and down accordingly. Hence, there shouldn't be any change in functionality and how the current limiters work. They still use the static values.

To avoid another accident, this MR introduces some significant enhancements:

• The ResizableSemaphore, which was the root cause of the prior incident, was rewritten completely. Instead of using a dedicated Goroutine for state management, it uses a mutex and a double-linked list to manage the waiters. When a caller wants to acquire a full semaphore, it is pushed to the last of the list. As all operations are synchronized, there is no need for spawning new goroutine.
• The limiter generalizes the current semaphore implementation, which uses two buffered channels. The MR introduces a feature flag for swapping in the new resizable semaphore gradually.
• Test coverage for both static and resizable semaphores to co-exist at the same time.

The new semaphore implementation also determines the official FIFO order of the queue. The current implementation uses buffered channels, hence the queue order is not guaranteed when the "concurrency" one is full. In the future, we are looking to apply LIFO order for more effectiveness during catastrophic events.

Manual tests

Two scenarios work well before and after gitaly_use_resizable_semaphore_in_concurrency_limiter flag is enabled

Per-RPC max queue length

[pack_objects_limiting]
max_concurrency = 2
max_queue_length = 2

Per-RPC max queue wait

[pack_objects_limiting]
max_concurrency = 2
max_queue_length = 10
max_queue_wait = "3s"