Add cumulativetodelta processor to default DDOT Collector metrics pipelines

[RiantZ]

What this PR does / why we need it:

Adds the cumulativetodelta processor to the default DDOT сollector configuration rendered by the datadog chart, in the metrics pipelines that export to the Datadog exporter:

• standalone Agent config: metrics and metrics/prometheus pipelines;
• Gateway config: metrics pipeline.

DDOT is moving to the metrics v3 payload format. In v3 the Datadog exporter stops converting cumulative counters to delta internally, so a cumulativetodelta processor in the pipeline becomes mandatory. Adding it to the default config now is safe before v3 — the exporter consumes already-delta input directly, without a second conversion — and prepares the chart for the v3 switch.

Special notes for your reviewer:

Placement — the processor is added only where the datadog exporter is present:

• It is not added to the daemonset Agent config used in gateway mode, because that config
  forwards metrics to the Gateway over otlphttp; the Gateway performs the conversion. This
  matches the chart's existing minimal-forwarding-agent design.
• It is not added to traces/logs pipelines. The processor only implements metrics
  processing, and the collector fails to start if it is placed in a traces/logs pipeline.

Checklist

[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

• All commits are signed and show as "Verified" on GitHub (see: [signing commits][1])
• Chart Version semver bump label has been added (use <chartName>/minor-version, <chartName>/patch-version, or <chartName>/no-version-bump)
• For datadog or datadog-operator chart or value changes, update the test baselines (run: make update-test-baselines)
• For datadog chart changes, received ✅ from a member of your team

https://datadoghq.atlassian.net/browse/OTAGENT-1178

[github-actions]

⚠️ GKE Autopilot / GDC Baseline Manifests Changed

This PR modifies GKE Autopilot or GDC baseline manifest snapshots. Before merging, confirm:

• GKE Autopilot/GKE GDC baseline manifest diffs have been reviewed and confirmed to be supported in GKE Autopilot and the latest Datadog WorkloadAllowlist.

If changes introduce constraints not yet covered by the Datadog WorkloadAllowlist CR, gate them with {{- if not (or .Values.providers.gke.autopilot .Values.providers.gke.gdc) }} until the WorkloadAllowlist is updated.
See gke-constraints-review-guide.md for the full constraint reference.

[mackjmr]

Do we need this change in helm / operator ? If we want to add it always, just adding it in the converter should be enough, and we would need to only maintain it in one place ?

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: eac324f112

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[chatgpt-codex-connector]

Keep stateful delta conversion off scaled Gateways

When otelAgentGateway.replicas is raised above 1 or the Gateway HPA is enabled, putting cumulativetodelta in the Gateway pipeline makes the first stateful conversion happen behind the chart's Gateway Service, which has no sticky routing. A single cumulative OTLP time series can therefore land on different Gateway pods across export requests; each processor instance only has its own in-memory previous point, so it will drop initial points or emit incorrect deltas and corrupt metrics for scaled Gateway deployments. Convert before the load-balanced hop or require deterministic routing for this default config.

Useful? React with 👍 / 👎.

[RiantZ]

Do we need this change in helm / operator ? If we want to add it always, just adding it in the converter should be enough, and we would need to only maintain it in one place ?

Automatic converter injection does not cover everything (as far I know, if I'm wrong - please tell me)

Standalone Agent (no gateway): the converter will inject c2d itself — but only from a future agent version (the datadog-agent converter change isn't in any release yet). Since the c2d processor is already compiled into every DDOT image, writing it in the config works on any version immediately. Here the explicit helm change is redundant once that agent version ships, but adds version-independence and visibility.

Gateway: the converter won't inject it at all. The chart overrides DD_OTELCOLLECTOR_CONVERTER_FEATURES (zpages,pprof,datadog), replacing the default list and omitting c2d. So the gateway needs either explicit config or c2d added to that env — otherwise it never gets it.

Core reason: the processor is in every image; converter auto-injection is a new, version-specific feature.

@mackjmr

[mackjmr]

Standalone Agent (no gateway): the converter will inject c2d itself — but only from a future agent version (the datadog-agent converter change isn't in any release yet)

I guess this depends when we want to support this by, wait for new agent version or add it now via helm but remove when new agent version is out.

Gateway: the converter won't inject it at all.

Can we inject it in converter for gateway ?

If we want to support this asap without waiting for new agent image im fine with adding it now as long as we add a todo to remove it with new agent version. But for changes like this that need to be added everywhere, I prefer that we add it only in the converter. Otherwise if we update the config we need to update it in 3/4 different places rather than just the converter.