feat(envoy-gateway): manage Envoy Gateway CRDs from rendered YAML

[grifonas]

Summary

Adds management of Envoy-Gateway-specific CRDs (gateway.envoyproxy.io/*) to the envoy-gateway module. Previously these were skipped due to skip_crds = true (which was added to avoid conflicts with the separately-managed upstream Gateway API CRDs from the gateway-api-crds module). On fresh installs or upgrades, the controller had no CRDs to watch.

This change uses the same file-based pattern as the gateway-api-crds module:

• One per-version YAML file in envoy-gateway/crds/ (rendered from gateway-crds-helm with crds.envoyGateway.enabled=true)
• Static manifest key map in envoy-gateway/locals.tf
• data "kubectl_file_documents" + kubectl_manifest with server-side apply + force_conflicts = true
• New scripts/update-envoy-crds.sh mirrors gateway-api-crds/scripts/update-crds.sh
• New .github/workflows/update-envoy-gateway-crds.yaml mirrors update-gateway-api-crds.yaml

Why not helm_release for the CRDs?

We tried in CON-2399 and hit Helm's 1MB release-secret limit. The gateway-crds-helm chart tarball plus rendered manifests exceeds the limit even when only one CRD set is enabled (Helm stores the entire chart in the release secret). The official Envoy Gateway docs explicitly recommend helm template | kubectl apply --server-side for exactly this reason. Doing the same here, but with a committed pre-rendered file so we stay within pure Terraform (no local-exec).

Version compatibility

The README now has a prominent compatibility note linking to https://gateway.envoyproxy.io/news/releases/matrix/. Key points:

• var.chart_version drives the controller AND the bundled Envoy Gateway CRDs (locked together)
• The upstream Gateway API CRDs are pinned independently by the gateway-api-crds module
• It is intentional today to run with newer Gateway API CRDs (v1.5.1) than what Envoy Gateway v1.7.x officially supports — the controller ignores unknown resource types until upgraded

Variable validation

var.chart_version is now validated via a terraform_data + lifecycle.precondition against the keys in chart_version_to_envoy_crds_map. Using an unsupported version produces a clear error at plan time:

Unsupported chart_version: "v9.9.9"

Supported versions: ["v1.7.1"]

To add a new version, run:
  ./envoy-gateway/scripts/update-envoy-crds.sh <version>

Or wait for the daily update-envoy-gateway-crds workflow to open a PR.

Test plan

• tofu init && tofu validate passes for the module
• CI on this PR passes
• Apply on Contiamo EKS in a worktree first to verify only kubectl_manifest.envoy_gateway_crds[*] resources are added (no destroys)
• Verify existing Gateway/HTTPRoute/EnvoyProxy resources unaffected
• Verify kubectl get crd envoyproxies.gateway.envoyproxy.io shows kubectl as a field manager after apply

Refs

• CON-2400
• Related: CON-2399 (script fix that informed this approach)