Add ParametersRef to Gateway.spec.infrastructure

[howardjohn]

What type of PR is this?

/kind gep

What this PR does / why we need it:

Follow up to #1868, which was down-scoped to only include labels and annotations to reduce friction on the initial GEP

Which issue(s) this PR fixes:

Fixes #

Does this PR introduce a user-facing change?:

A new `parametersRef` field has been added to `Gateway.spec.infrastructure`. This allows configuration of arbitrary implementation-specific parameters. This field previously existed only on `GatewayClass`. 

[robscott]

Thanks @howardjohn! Definitely a stretch to get into v1.1 given the timeline, but since this is just a part of a GEP that was already promoted to experimental, it seems like there might be a small chance it could fit in if we don't run into any significant issues.

[robscott]

This allows for cross-namespace references, I'm not sure we want to allow for that. The corresponding GEP doesn't make it obvious if those are needed, do you mind updating the GEP to clarify the goals here?

[howardjohn]

I made a new LocalParametersReference to force it to be same namespace

[robscott]

I think we need to describe how merging works if/when this is configured at both layers.

[howardjohn]

Added

[mikemorris]

Would like to see this get in!

For context, GEP-1867, which is currently in Experimental status, covers the background motivation and why GatewayClass parametersRef is not sufficient, and #2911 is an example of a specific issue that arose from the tension between how GatewayClass parametersRef was intended/suggested to be used (as a template), and the role that it's being stretched into filling in practice because of the gap that adding this Gateway-scoped option for implementation-specific dynamic configuration would help solve.

A summary of the feedback that blocked adding this during API review previously can be found at #1757 (comment) and additional supporting context for how Gateways are being used (and who is configuring them) to justify this need can be found in #1653 (comment).

@howardjohn Would this solve the core need in #567?

[howardjohn]

@mikemorris from my POV this is good enough to close #567

[youngnick]

I'm still a little worried that this will drop the incentive for people to bring further changes to infrastructure upstream (since you can now do whatever you want in your own paramsRef), but not enough to hold off on this. I would really like to see us consider what things end up in custom paramsRef objects that should be lifted out into standard infrastructure fields instead.

That said,

/approve

[howardjohn]

fwiw I don't think we have plans to implement paramsref in istio in the near term so we are incentivezed to keep pushing for first class fields once this lands :-)

[howardjohn]

/assign @robscott

[shaneutt]

/approve
/lgtm
/unhold

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: howardjohn, mikemorris, shaneutt, youngnick

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [shaneutt,youngnick]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[robscott]

/lgtm