CFP: Gateway API support should work even when experimental CRDs are not present

[youngnick]

Cilium Feature Proposal

Is your proposed feature related to a problem?

Gateway API v1.1 moved the GRPCRoute resource from Experimental to Standard and, at the same time, bumped the apiVersion from v1alpha2 to v1.

This means that, if you change from Gateway API v1.0 experimental to v1.1 standard, the Cilium operator will fail to start, because it currently requires that all experimental resources are present in the cluster. To put this another way, Cilium's Gateway API support currently will only work with the Experimental channel, which is not very conducive to the idea of Standard being the most stable Gateway API version.

Describe the feature you'd like

The Cilium operator's Gateway API controllers should consider experimental resources like TLSRoute or BackendTLSPolicy as optional, so that Cilium can support either the Experimental or Standard Gateway API releases.

(Optional) Describe your proposed solution

This should be possible by changing the startup and code of the Gateway API controller-runtime manager to only enable processing of Experimental CRDs if they are present in the cluster. Practically, this will mean that the presence-checking code we already have will need to be a bit more complex, and pass config that will allow the Reconcilers to be optionally added if the CRDs are present.

[youngnick]

This came up because of kubernetes-sigs/gateway-api#3075 and other reports of upgrade problems.

We may also need to add some upgrade instructions to the Gateway API instructions.