Auto-restart Datadog agents on API key change in a K8s Secret

[dmgress]

What does this PR do?

When the API key is stored in a Kubernetes Secret, the reconciliation code adds a SHA256 hash of the secret's data as a new environment variable. This change spreads to all objects.

So, if the secret's data changes, it triggers a rolling update for the cluster agent ReplicaSet and agent DaemonSet, making them use the new API key.

Motivation

The Datadog agent doesn't update secrets already in memory, like the API key. If the API key is changed and the old one is revoked, the agent and cluster agent can't send data until they are restarted with the new key.

Even though data is buffered, there might be a temporary gap and a risk of data loss if the agents can't send data.

Using Kubernetes' built-in methods to update the agents when the key changes avoid the need for custom code. Not using labels and annotations prevents the accidental creation of custom metrics.

Additional Notes

No notes

Minimum Agent Versions

Not applicable, changes are on the reconciliation code.

Describe your test plan

I created additional test cases in internal/controller/datadogagent/controller_reconcile_v2_test.go and also manually verified the change works in a kind cluster

Manual test plan:

1. I created new API and application keys in Datadog
2. I started a kind cluster with two workers nodes
3. I created the kubernetes secret to hold the API and application keys
4. I applied the datadog operator with the change and created a DatadogAgent object using examples/datadogagent/datadog-agent-with-secret-keys.yaml
5. I verified the new env variable is present on the cluster agent and agent instances
6. I deployed an application on the cluster to get a metric going
7. I revoked the API and observed the agent couldn't send new metric data
8. I created a new API key and set it in the secret
9. I observed the change in the value of the new env variable and the rotation of instances
10. I observed the metric data could be send again

Checklist

• PR has at least one valid label: bug, enhancement, refactoring, documentation, tooling, and/or dependencies
• PR has a milestone or the qa/skip-qa label