[BUG] A slow Admin delays independent heartbeats to all subsequent Admins #7743

Current behavior

Independent HeartbeatListener runs a single periodic reporting task with a five-second target period. sendHeartbeat loops over the configured Admin list sequentially; token loading/login and RegisterUtils.doHeartBeat are synchronous network calls. Catching a failure allows the loop to continue only after that call returns or times out.

A slow first Admin therefore delays reports to otherwise healthy later Admins and delays the next reporting round. An endpoint that streams an unfinished response slowly enough to avoid individual read timeouts can occupy the call well beyond the twenty-second Admin liveness threshold. Several ordinary timeout delays can also accumulate across the list. This can cause healthy destinations to observe stale/missing heartbeats even though they are reachable.

Source evidence

• Single scheduled task and sequential send loop
• Synchronous heartbeat operation
• HTTP timeout configuration and blocking response-body read

Source-confirmed serialization of work; no real multi-Admin fault test was run during issue preparation. Impact depends on the duration of the blocked operation and reporting policy.

Acceptance criteria

• Use a controlled slow/stalled first Admin and a healthy second Admin to demonstrate the reporting delay, without long sleeps.
• Define an end-to-end deadline for each destination, covering login, network phases and response consumption.
• Isolate destinations using bounded independent scheduling/asynchronous work or a similarly bounded design. Prevent overlapping retries and unbounded work queues.
• A slow/unreachable destination does not starve reports to a healthy destination beyond the documented liveness budget.
• Test token-loading stalls, slow bodies, ordinary failures, recovery and shutdown cancellation; retain per-destination token ownership.
• Report cadence/deadline settings and resource bounds are documented; do not simply add an unbounded thread pool.

Related: #7725 concerns reauthentication after token rejection; #6608 concerns uncaught exceptions cancelling schedules. Neither isolates long-running successful/pending calls.