node: concurrent router dials, ready on the first, redial a dropped router; pace router rollouts

[aojea]

Follow-up to #612, from what its instruments showed on bananas in the first hours.

Findings

1. Cold join cost the sum of the router dials, plus a full timeout for any router that had gone. Start dialed the configured routers one after another and returned only when every dial had ended. With four live routers a member took 6.05 s to /readyz; while the control plane still listed the previous GCE router (it does for its lease's 15 minutes after every deploy), 7.6 s. The six members of the first harness run all showed the same 6.05 s.
2. A router rollout took every session a member had. The first rollout under the soak fleet restarted the three routers in 45 s (next pod as soon as the previous passed its 5 s startup probe). The node only re-handshakes a router from the connection monitor, which acts once no router is left and only on its one-minute interval, so all 20 members lost all three routers with no handshake in between and were off the mesh for 7–63 s. A router restarting alone was never re-handshaken at all: a member kept one router fewer after each rollout. SamCanaryMemberDisconnected (5 m) correctly stayed silent.
3. The deploy failed on a 120 s control-plane rollout wait. The new pod's containers were ready in 15 s, but GKE's NEG readiness gate took minutes (34 s on the previous deploy). The rollout finished on its own; every later step, canaries and the soak fleet included, was skipped until a rerun.

Changes

• node: dial the routers at once, be ready on the first, and redial one that drops — router addresses are resolved and grouped by peer (a router advertised under several addresses, or by several entries resolving to the same records, is one peer with all of them: one dial over whichever address answers, one handshake; static relays are now 4 peers, not 20 entries). The routers are dialed concurrently and Start returns as soon as one admits the node. A dropped router is redialed in the background with a doubling delay from 2 s, six attempts, one redial per router at a time; RouterRedialDelay / RouterRedialAttempts expose it. Cold join on bananas: 6.05 s → 2.3 s.
• deploy, chart: hold a router rollout 90s between pods — minReadySeconds: 90 on the router StatefulSet (testnet manifest and router.minReadySeconds in the chart), so a rollout waits for members to re-attach before taking the next router.
• deploy: give the control plane and router rollouts the time they take — both waits 600 s.

Tests

• TestStartIsReadyOnceOneRouterAdmitsTheNode: a live router and a listener that accepts and never speaks; Start returns in 20 ms rather than the dead router's 3 s timeout (fails at 3.01 s against the old loop).
• TestRouterPeersGroupsAddressesByPeer: three entries for one router → one peer, two distinct addresses.
• TestRouterDropIsRedialed: the router closes the connection, the node re-handshakes on its own within the redial delay, twice in a row (fails without the redial). TestRouterDisconnectClearsAuthenticatedSession opts out of the redial, since it tests the state in between.
• go test ./... green, make lint clean, router-path tests under -race ×2, each commit builds on its own. Router template dry-run on kind; helm lint clean.

[gemini-code-assist]

Code Review

This pull request introduces a concurrent router dialing mechanism and a background redial loop with exponential backoff to handle dropped router sessions, improving node resilience during router rollouts. It also updates Kubernetes and Helm templates to configure minReadySeconds for routers, and adds comprehensive tests to verify these behaviors. Feedback on the changes suggests adding an early check in ConnectAndAuthWithRouter to handle empty router lists gracefully and avoid returning a nil error, as well as logging failures when loading identity credentials during background redials.

[aojea]

Addressed both review comments in 68e8aa7 (an address that resolves to no router peer is now named in the error; a redial that cannot load the identity logs why it gave up) and bumped golang.org/x/net to v0.60.0 in d612b64 for the govulncheck findings GO-2026-6603/6611/6612/6617. Full go test ./... green.