userspace-dp: singleflight-guard + bound the neighbor prewarm scan (#5104)

[psaab]

Problem (#5104, verified on origin/master 865fad6)

The manager status loop launched a full async neighbor-resolve prewarm
scan on every 1s tick for the first 60s (then every 10s on HA standby)
with no in-flight guard. Each scan did route-indexed NeighList dumps
and spawned one goroutine per resolve target. Under slow netlink or a
large RIB a scan can outlast its tick, so scans overlapped — multiplying
concurrent scans and probe goroutines (target dedup was per-scan only). This
turned HA readiness warming into self-amplifying control-plane load, delaying
apply/status/recovery.

Fix

Bound the cold-path work per status tick:

1. Singleflight — a lock-free neighborPrewarmInFlight atomic.Bool CAS
   guard in proactiveNeighborResolveAsyncLocked coalesces overlapping ticks
   onto the running scan; a second scan never starts while one is in flight.
   The guard clears when the scan goroutine returns (defer, so a panic also
   clears it), matching the existing rgTransitionInFlight pattern.
2. Deadline + cancellation — each scan runs under a 15s
   neighborPrewarmDeadline context and checks it between netlink dumps, so a
   slow netlink layer cannot pin the guard indefinitely; the next tick spawns
   a fresh scan. (vishvananda/netlink calls are not context-cancelable
   mid-syscall, so the deadline bounds the between-dump loop, not a single
   wedged syscall.)
3. Bounded probe pool — runBoundedNeighborProbes fans probes out through
   a fixed 8-worker pool (neighborPrewarmProbeWorkers) instead of one
   goroutine per target.
4. One dump per link per scan — the scan caches NeighList(FAMILY_ALL)
   per link index, collapsing the old per-route re-dump.

An injectable neighborPrewarmScan seam allows deterministic tests without
real netlink.

Test (merge gate)

TestNeighborPrewarmSingleflightCoalescesOverlappingTicks5104 fires
overlapping ticks while a scan is artificially in flight (blocked in the
injected seam) and asserts only one scan runs (peak concurrent scans == 1,
started == 1). Companion tests assert the bounded probe pool (200 targets →
peak ≤ 4 workers) and the ctx-cancel wiring.

• Parent-RED verified: neutralizing the CAS guard makes the named test RED
  (concurrent prewarm scans peaked at 2, want 1) as an assertion failure,
  not a build break. target-count = 1.

Validation

• go test -race ./pkg/dataplane/userspace/... — full package green; named
  test x3 for flake.
• gofmt + go vet clean.

Docs

docs/userspace-cold-start-fix-plan.md records the singleflight + bounded +
deadline-bounded prewarm behavior.

HA / smoke assessment

This touches the HA-readiness-warming path, but the guard is unit-provable via
the injected scan seam and the fix only reduces control-plane load without
changing the probe behavior (same sendICMPProbeFromManager per target). No
loss-cluster smoke warranted.

Closes #5104

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.