Pause replication streams when the scheduler is under pressure.

[robholland]

What changed?

Pause replication streams when the scheduler is under pressure.

Why?

This allows us to apply backpressure to replication streams when we cannot keep up with the load. The schedulers are shared amongst streams so just keep tracking of tasked tasks is not enough. We use a timer to notify us if a submit is taking too long rather than recording the time after the fact so that the backpressure is more reactive.

How did you test it?

• built
• run locally and tested manually
• covered by existing tests
• added new unit test(s)
• added new functional test(s)

---

Note

Implements latency-aware backpressure for replication stream receiving.

• Add history.ReplicationReceiverSubmissionLatencyThreshold and history.ReplicationReceiverSlowSubmissionWindow dynamic configs; plumbed through configs.Config
• Stream receiver now measures scheduler Submit latency, records per-priority slow submission timestamps, and exposes them to flow control
• Flow controller pauses when taskTrackingCount exceeds ReplicationReceiverMaxOutstandingTaskCount or a slow submission occurred within the configured window
• Refactor scheduler routing: new getTaskSchedulerPriority plus existing getTaskScheduler; add thread-safe tracking of last slow submissions
• Add unit tests for flow control slow-submit behavior and update stream receiver tests; minor stability tweak to panic-capture test

^{Written by Cursor Bugbot for commit 6cc7a01. This will update automatically on new commits. Configure here.}

[yux0]

think about pending task count

[yux0]

LGTM. Can we add a feature flag on this?