feat: eBPF vrf_table GC sweep and control-daemon startup

[privateip]

Summary

Adds SweepEBPFVRFTable, a GC pass that reconciles the eBPF uSID datapath's vrf_table map entries against live BGPVRFInstance CRDs, using a generation-cutoff scheme to avoid a register/sweep race. This runs from galactic-cni's run container rather than galactic-router's existing GC controller: the pinned vrf_table map only exists inside that container, which has the /sys/fs/bpf hostPath mount and CAP_BPF that galactic-router's DaemonSet doesn't need for anything else. routerNamesForNode gains a fuller sibling, routersForNode, since the sweep needs each router's full Spec.SRv6Locator, not just its name.

Wires installer.Run to load/attach/pin the eBPF datapath at startup, serve /metrics (Prometheus), report an ebpf-datapath gRPC health sub-service, and run the GC sweep on its own ticker. Adds a --metrics-port CLI flag to galactic-cni run.

Note

This depends only on #283 (the datapath control-plane packages), not on the CNI ADD cutover in #285/#286 — the sweep reconciles directly against BGPRouter/BGPVRFInstance CRD state rather than anything registerEBPFDatapath writes, so it's a sibling branch in the stack rather than stacked on top of the CNI cutover.

Test plan

• go build ./...
• go vet ./...
• go test ./internal/gc/... ./internal/installer/... ./cmd/...
• task lint (0 issues)

Part of the eBPF uSID datapath cutover stack (base: #283).

[ecv]

Rewritten after reading the rest of the stack, #283 through #289; one of my original questions was already answered by #288, and two others turned out to have direct evidence behind them.

Two things worth crediting first: capturing the generation cutoff before listing the CRDs, and bailing out entirely when zero BGPRouters come back rather than treating that as "zero live attachments." The second is the kind of guard that usually only gets written after it has already wiped a node once.

1. The sweep reconciles vrf_table only, but registration writes all three maps. LocatorTable and FunctionTable both already implement Unregister in feat: eBPF uSID datapath control-plane packages #283 — as far as I can tell nothing calls either one, and only VRFTable has a Reconcile. So locator and function entries accumulate with no reclamation path at all, against caps of 64 and 128. A node whose SRv6Locator changes — renumbering, or the secondary /48 block that feat: Datum Cloud IPv6 addressing plan enhancements#740 documents as the route past 4,095 instances — strands the old block's entries permanently, and at 64 accumulated blocks registration starts failing, which the cutover surfaces as a failed pod ADD rather than a datapath drop. Is locator/function GC deliberately deferred, or is the assumption that locators never change in practice?

2. The zero-routers guard protects against a mass wipe, but the same case one level down isn't guarded, and Reconcile has no internal safety of its own — anything absent from live and below the cutoff is deleted unconditionally. So an instance skipped by the caller for an empty or unparseable SRv6Locator, or an out-of-range VRFID, is not merely ignored: it is reaped on that same tick, and a live pod loses its datapath entry over a transient or malformed CRD field. Worth noting the contrast with fix: SEG6 encap mode, IPv4 SID advertisement, reconcile skip-on-error #289, which deliberately adopts skip-and-continue in the router's advertisement build — there the cost of skipping is "this path isn't advertised," here it's "this entry is deleted." Same idiom, very different blast radius. Should a skip for any reason other than "not one of our routers" abort the reconcile for that tick?

3. feat: Grant CNI DaemonSet BPF privileges and wire up e2e #288 wires ebpf-datapath to both a liveness and a readiness probe, 10s period, no failureThreshold (so the default 3). The health check re-resolves the interface set on every call and reports unhealthy on a transient ResolveInterfaces failure — its own comment calls that "occasionally noisy" and correct for a readiness signal, which I agree with. On liveness it means roughly 30 seconds without a default route restarts the container, on every affected node at once. Restarting does re-attach, so it self-heals, but the netlink watch loop already exists to do exactly that. Is liveness on this signal deliberate, or would readiness alone (plus the watch loop) cover it with less amplification?

4. The metrics server starts after the datapath, and a datapath failure is fatal to Run. So the failure mode most worth observing — preflight rejection, crashlooping container — is the one where nothing is ever scraped and the only signal is container logs. Worth starting the metrics listener first so a failed startup is still visible on /metrics, or is the crashloop considered signal enough?

5. The type assertion on the datapath start's return value means the test fake, a plain closer, leaves metrics, health, and GC wiring inert — as your own comment notes. That's honest, but it also means the tests cover "Run starts and shuts down" rather than any of the three tick paths this PR adds. Would having the start function return an interface the fake can satisfy be worth it to get the health and sweep branches under test?

Smaller: the resolved interface list is stored in the datapath state and never read again, since the health handle re-resolves internally. And the reconcile error path bumps the error count by one regardless of how many deletions failed, so the count reads as "this sweep had errors" rather than a magnitude.

Same CI note as the rest of the stack: this targets pr2-ebpf-datapath, and the workflow's branches: [main] filter means none of the tests here have actually run in CI yet.