Migrate to Gateway API v1alpha2

[skriss]

Epic-level issue for collecting the work needed to add support for v1alpha2 Gateway API.

WIP task list:

• new API group (gateway.networking.k8s.io instead of networking.x-k8s.io)
• Updates to Gateway <-> Route binding API
• cross-namespace reference changes
• removal of TLS cert references from HTTPRoute (we don't support this now anyway, just make sure there are no error conditions or anything)

[youngnick]

HTTP Header matching is now extended support for HTTPRoute, see kubernetes-sigs/gateway-api#733. I think we probably should do this?

[xaleeks]

@youngnick What does extended support mean exactly? Also, do you mean should we support method based routing in HTTPProxy as well? It’s a useful feature to be able to specify the method to match against. And I think we should keep things at parity for the time being. Thoughts?

If we support it, do we also support specifying multiple methods?

[youngnick]

In the Gateway API, there are three types of support:

• Core (which all implementations MUST support)
• Extended (which implementations MAY support, but the behavior is mandated by the spec)
• Custom (implementations MAY support it, but it probably won't be cross-implementation compatible).

I thought we should probably do header matching since we have a similar thing in HTTPProxy already.

[skriss]

Moved into 1.20 since it's unlikely we'll get this done for 1.19.

[skriss]

I'm actively working on this. Step 1 is getting existing code to compile and tests to pass with the v1alpha2 API. Steps 2..n are adding support for new features in v1alpha2.

[skriss]

HTTP Header matching is now extended support for HTTPRoute, see kubernetes-sigs/gateway-api#733. I think we probably should do this?

(assuming you mean HTTP method matching) yep makes sense to add, it's pretty trivial, and we do already effectively have support for it for HTTPProxy - see #2679 (comment).

Filed #4088.