Add an experimental prepared blue-green Agent rollout

[AliDatadog]

Why

The current node-Agent DaemonSet stops a working Pod before Kubernetes schedules, pulls and starts its replacement. A slow or failed replacement can therefore leave the node uncovered. Native DaemonSet surge does not solve the full problem: the prepared Agent must sleep to avoid host-resource conflicts, so ordinary readiness cannot both mean “prepared” and “healthy.”

This PoC separates preparation from serving while keeping unavailability bounded like a RollingUpdate.

What does this PR do?

Adds an annotation-gated, experimental prepared blue/green rollout for Linux node Agents:

experimental.agent.datadoghq.com/node-agent-rollout-mode: prepared-blue-green-v1

The Operator maintains two OnDelete DaemonSets and three durable per-node states:

1. Source: the current Agent serves alone.
2. Overlap: the source serves while the exact target Pod is scheduled, pulled and sleeping.
3. Target: source removal is committed; the target activates and must become Kubernetes Available.

Before source removal, every target container must be Running without a restart, and the Operator must observe the same target Pod UID in two reconciliations. After source removal, the target consumes the configured maxUnavailable budget until its exact revision is Ready for the DaemonSet's minReadySeconds. The current generated DaemonSets leave minReadySeconds at Kubernetes' zero-second default; the experimental deployment will configure maxUnavailable: 5%.

If a sleeping candidate restarts while the source remains Available, the Operator deletes only that target Pod so its OnDelete DaemonSet retries it. A recovered exact-revision target can complete handoff when the source is already unavailable.

The transformation preserves the configured network mode. With hostNetwork: true, it removes declared container ports so Kubernetes does not reserve duplicate host ports; the active process still binds the original node ports. Green core Agents use command port 5002 to isolate known mixed-generation local control traffic. A hostPath lock serializes each same-named component's UDS and listener ownership.

Important trade-offs

• Source removal happens before the target Agent has parsed configuration or proved functional health. Pre-Available failures consume the budget and stop further handoffs once it is full; automatic rollback is not implemented.
• A failure after a target already became Available can occur after later handoffs started, as with native RollingUpdate. The 5% budget is not a canary or rollback mechanism.
• CPU, memory or Pod-capacity failures use a budget-bounded delete-first fallback. That node retains baseline pull/startup downtime.
• Locks prevent simultaneous ownership; they do not transfer UDS/UDP queues, Agent caches, Cluster Agent assignments, workloadmeta state or host identity.
• Joining-node generation coherence, overlapping deployment isolation, cache-transform compatibility and largest-cluster control-plane cost remain explicit pre-staging work.
• Opt-out returns service to blue, removes green and rollout labels, then restores the conventional DaemonSet.

Minimum Agent versions

• Agent: companion PoC build containing agent-rollout-gate
• Cluster Agent: unchanged

Companion Agent PoC: DataDog/datadog-agent#54832

Test plan

Passed locally on the final merged tree:

• go test -p 1 ./internal/controller ./internal/controller/datadogagentinternal ./internal/controller/datadogagent -count=1
• make lint — 0 issues
• make verify-licenses

No experimental-cluster rollout has been performed yet. After review, validate conventional-to-prepared migration, fresh install, prepared-to-prepared update, new-node behavior, insufficient-capacity fallback, failed pulls/startup and opt-out.

Checklist

• PR has at least one valid label: enhancement
• PR has a milestone or the qa/skip-qa label
• All commits are signed