[Flow Control] Benchmark: Scale testing for Flow Control

[LukeAVanDrie]

What would you like to be added:

We need to establish a set of Go benchmarks to quantify the upper limits of the Flow Control layer, specifically focusing on the overhead of maintaining a large number of active queues (Flows).

Why is this needed:

As we onboard new users, a common question is "How many Fairness IDs (Queues) can we support?" (e.g., per-user fairness in a large MaaS app). We need concrete data to answer this.

Specific Benchmarks needed:

1. Memory Overhead: Cost per Flow (Queue + Policy + Metrics) in the Registry.
2. Dispatch Cycle Latency vs. Flow Count:
   • The BestHead inter-flow policy currently iterates over candidates. We need to measure how dispatch cycle latency degrades as $N_{flows}$ scales from 10 to 10,000.
3. Goroutine Saturation: Since each buffered request holds a blocking goroutine, we should stress test the system with high concurrency (e.g., 50k+ buffered requests) to identify bottlenecks in the Go runtime scheduler or memory pressure.

Acceptance Criteria:

• go test -bench results added to the repository or documentation.
• Identification of the "Knee of the curve" where performance degrades unacceptably.

[LukeAVanDrie]

I don't think we need proper scale testing for this as all flow control constraints are purely on CPU / mem. go test -bench should be sufficient for a sanity check.

[amy]

cc/ @amy