api: remove ListenerReasonUnsupportedExtension

[mikemorris]

What type of PR is this?

/kind cleanup
/kind documentation
/kind api-change
/kind deprecation

What this PR does / why we need it:
This appears to be an artifact of the v1alpha1 configuration style where a listener selects routes directly. If I understand correctly, this is a reference to the ExtensionRef field on HTTPRouteRule (and other xRouteRule objects), which are the only other uses of the term Extension currently in the spec codebase.

UnsupportedExtension should likely become a RouteConditionReason instead, but I'm not quite sure with which RouteConditionType it should be used.

The intended behavior now is a bit unclear (it's an edge case not currently described in #1112). While rejecting a route entirely because of a single unsupported filter on one rule might have a large blast radius, I'm thinking through a few possible scenarios and potential impact/mitigation and wondering if that might actually be okay (and might even be desirable if using ExtensionRef to implement something like JWT auth):

• Moving from one Gateway API implementation to another - some degree of breaking change is likely expected here and would hopefully be discovered in a test environment and mitigated manually.
• Upgrading a Gateway API implementation to a new version which drops support for an old filter - this seems like something that should be clearly identified by the implementation as a breaking change in a changelog or mitigated safely through a deprecation process.
• Attempting to add a new filter to an existing route rule and making a typo - this feels like the most likely common operator risk, could we perhaps suggest implementations add custom webhook validation for this field to prevent accepting invalid ExtensionRef configurations that cause an attached route to become detached?

Which issue(s) this PR fixes:

Refs #1077, #935 (comment)

Does this PR introduce a user-facing change?:

removes the UnsupportedExtension ListenerConditionReason intended for a route selection model that has changed in the v1alpha2 API

[k8s-ci-robot]

Hi @mikemorris. Thanks for your PR.

I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[robscott]

/ok-to-test

[robscott]

I agree that this removal makes sense. We should not detach a listener if a Route fails to attach to it. I think we should create a follow up issue to discuss what we should do instead of this. Will leave this for @hbagdi, @youngnick, or someone else to sign off. Or we can get final sign off at community meeting on Monday.

/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: mikemorris, robscott

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 [robscott]

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

[youngnick]

/lgtm

I agree this should go, and we can follow up the extra edge cases separately.

[youngnick]

/retest