Move envoy management to calico

[MichalFupso]

Description

This PR replaces operator's local helm-template recipe for pkg/render/gatewayapi/gateway_api_resources.yaml with a cp out of the existing fetch-calico-crds clone, making projectcalico/calico's third_party/envoy-gateway/Makefile the single source of truth for the Envoy Gateway version, the rendered manifest, and the operator's go.mod github.com/envoyproxy/gateway pin.

The new update-envoy-gateway-resources target is wired as a prereq of gen-versions-calico, so the existing hourly sync-versions.yml workflow automatically pulls envoy-gateway changes from calico — no new workflow needed; updates land in the same auto-PRs that already sync CRDs and component versions.

The operator's ENVOY_GATEWAY_VERSION pin, the $(ENVOY_GATEWAY_RESOURCES) helm-template recipe, and the HELM3 download machinery (only consumer was that recipe) are all deleted. As a bonus, update-envoy-gateway-resources also parses ENVOY_GATEWAY_VERSION out of calico's Makefile and bumps operator's go.mod github.com/envoyproxy/gateway line in lockstep via go mod edit + go mod tidy.

Paired with projectcalico/calico#12757

Release Note

TBD

For PR author

• Tests for change.
• If changing pkg/apis/, run make gen-files
• If changing versions, run make gen-versions

For PR reviewers

A note for code reviewers - all pull requests must have the following:

• Milestone set according to targeted release.
• Appropriate labels:
  • kind/bug if this is a bugfix.
  • kind/enhancement if this is a a new feature.
  • enterprise if this PR applies to Calico Enterprise only.

[nelljerram]

Love this, thanks @MichalFupso !

[electricjesus]

Two small gaps in the new procedure worth tightening, both non-blocking:

1. Operator step 1 (the manual go mod edit + make mod-tidy) is partially redundant with the auto-flow. The new update-envoy-gateway-resources target (Makefile L680–688) already parses calico's pin and runs go mod edit -require=github.com/envoyproxy/gateway@<new> && go mod tidy whenever the pins differ. So if a human is doing the bump manually (i.e. not via the hourly sync-versions.yml auto-PR), running make gen-versions would also handle go.mod. Could you either drop step 1 in favour of "run make gen-versions, which bumps go.mod and refreshes the YAML in one shot", or add a sentence clarifying why you'd want to bump go.mod first (e.g. "do this explicitly so the GO_BUILD_VER bump shows up before you touch the rendered YAML")? Right now a reader might do it both ways and produce a confusing diff.

2. The calico-side procedure (steps 3–4) won't actually run via Renovate. Renovate is configured for envoy-gateway patch bumps only, and it doesn't touch the matching envoy-proxy/envoy-ratelimit versions or the patch-stack refresh. The doc reads as if "Renovate normally does step 1+2" implies Renovate handles the whole thing — it doesn't. For minor/major bumps, a human still has to follow steps 3–4. Worth a one-liner under step 1 like: "Renovate only handles patch bumps and only regenerates the helm output; minor/major bumps still need steps 3–4 by hand."