gcp: support sidecar containers + addons/gcp/otel-sidecar

[robbiet480]

Summary

Adds two inputs to the gcp module so callers can colocate sidecars (typically OpenTelemetry collectors) with the fleet-api Cloud Run service, plus a new addons/gcp/otel-sidecar addon that emits the matching Fleet env vars.

• var.sidecar_containers (list of container objects) — wires arbitrary sidecars into the Cloud Run service. Matches the upstream cloud-run module's container schema. Useful for any collector exposing an OTLP receiver on a localhost port (Datadog DDOT, otelcol-contrib, Grafana Alloy, Honeycomb agent, …).
• var.service_only_env_vars (map) — env vars applied to the Cloud Run service but not the migration job. Needed for vars that depend on a sidecar being present, e.g. OTEL_EXPORTER_OTLP_ENDPOINT=http://localhost:4317 — the migration job (a Cloud Run Job) has no sidecars, so it would log exporter retry noise during each migration if those vars leaked in.
• addons/gcp/otel-sidecar/ — emits the FLEET_LOGGING_TRACING_ENABLED, FLEET_LOGGING_OTEL_LOGS_ENABLED, OTEL_EXPORTER_OTLP_*, and OTEL_RESOURCE_ATTRIBUTES env vars in a {universal, service_only} split so callers route them correctly. Doesn't ship a sidecar container itself — the README has copy-pasteable examples for OpenTelemetry Collector contrib and Datadog DDOT.

Follows the addons/gcp/* convention established by #223 (okta-conditional-access) and #231 (pubsub-to-bigquery).

Why

Fleet's server has built-in OpenTelemetry exporters for traces, metrics, and logs (otlptracegrpc, otlpmetricgrpc, otlploggrpc — all gRPC). The pattern that actually works on Cloud Run is: run an OTel collector as a sidecar in the same instance, point Fleet at localhost:4317, let the collector forward to whatever backend.

Today the gcp module only renders a single container per service, so there's no clean way to express this. Direct OTLP intake from Fleet to a SaaS backend isn't a workable substitute — Datadog's direct intake is HTTP-only and requires delta temporality, neither of which Fleet supports without source patches.

Comparable prior art: addons/xrays-sidecar does the same job for AWS X-Ray on ECS. This PR fills the GCP gap.

Backwards compatibility

Both new inputs default to empty ([] and {}). With defaults, the rendered output is functionally identical to today — only field added is container_name = "fleet" on the main container (forces one revision swap on first deploy after upgrade, no behavior change).

The migration job is untouched. The fleet-service Cloud Run service gets the new container name + a depends_on only when callers actually pass sidecars.

Prerequisite

Multi-container Cloud Run services require GoogleCloudPlatform/terraform-google-cloud-run#450 (open, mergeable, awaiting maintainer review) to land. That PR fixes a lookup() != {} skip in the v2 module's dynamic "ports" block that prevents sidecars from opting out of the ingress port. Until it merges, attempting terraform apply with non-empty sidecar_containers fails with:

Error 400: Revision template should contain exactly one container with an exposed port.

I've called this out clearly in the addon README and the var.sidecar_containers description. Callers can vendor the patched module locally as a workaround — that's how the production deployment this PR is extracted from runs today.

This PR is fine to merge before #450; the new inputs default to empty so nothing breaks for existing users, and the new code path becomes useful once #450 ships.

Validation

• terraform fmt -recursive + terraform validate clean for both gcp/ and addons/gcp/otel-sidecar/.
• The runtime behavior — Fleet's OTel SDK shipping traces, metrics, and logs through a DDOT sidecar (gcr.io/datadoghq/agent:latest-full + DD_OTELCOLLECTOR_ENABLED=true) to Datadog us5 — is live in production at Campus today, on both a primary fleet-api service and a secondary bulk service. Verified all three signal types land in Datadog APM Traces, Metrics Explorer, and Log Explorer.

Test plan

• On a clean GCP project, set sidecar_containers = [] and service_only_env_vars = {} → confirm no infrastructure change from current main.
• After fix: permit optional ports for sidecars so we can run sidecars GoogleCloudPlatform/terraform-google-cloud-run#450 lands, add a sidecar per the addon README's "OpenTelemetry Collector (contrib)" example → confirm Fleet's /healthz stays passing and OTel data reaches the collector (e.g. via the debug exporter).
• Confirm the migration job (Cloud Run Job) does not receive OTEL_EXPORTER_OTLP_ENDPOINT after wiring service_only_env_vars.

[BCTBB]

@robbiet480 Thank you for your contribution! We'll schedule the review of your proposed changes for next sprint.

[erikngo]

@BCTBB that's quite important fix, it blocks the pattern sidecars for cloud run now via official tf module, we need to make forked module for working around this right now.