api: add RouteReasonNotAllowedByListeners

[rainest]

What type of PR is this?
/kind feature

Optionally add one or more of the following kinds if applicable:
/kind api-change

What this PR does / why we need it:
Adds two RouteConditionReason constants for RouteConditionAccepted==false:

• NotAllowedByListeners indicates that none of the Gateway's Listeners have an allowedRoutes that permits the route.
• NoMatchingListenerHostname indicates that none of the Gateway's compatible Listeners have a Hostname that matches one of the route's hostnames (and implicitly that there is no compatible Listener without a Hostname, which would match any route).

Which issue(s) this PR fixes:
Related to #1077

Does this PR introduce a user-facing change?:

adds RouteReasonNotAllowedByListeners and RouteReasonNoMatchingListenerHostname RouteConditionReason constants

[k8s-ci-robot]

Hi @rainest. 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]

Thanks @rainest!

/ok-to-test
/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: rainest, 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

[rainest]

I had a brief discussion with @mikemorris re separating NotAllowedByListeners into separate constants for AllowedRoutes Kind and Namespace sections to be more specific and allow more targeted conformance tests, but I don't think we can do this since we're checking a route against all available Listeners, and can encounter scenarios like:

namespaceFoo/TCPRoute

ListenerA.allowedRoutes: (namespace selector for some label present on namespaceFoo), (kind UDPRoute)
ListenerB.allowedRoutes: (namespace selector that _does not_ match namespaceFoo), (kind TCPRoute)

where the answer to "was the route denied because of AllowedRoutes.Kinds or because of AllowedRoutes.Namespaces?" is "Both?".

Therefore, conformance tests should probably test that each of "only rejected because of Kind criteria", "only rejected because of (each type of) Namespace criteria", and mixed cases like the above result in the same NotAllowedByListeners.

Intuitively, I'd expect that Hostname checks, and receiving status NoMatchingListenerHostname, are performed after AllowedRoutes checks, and that routes should not expect to see NoMatchingListenerHostname if they also qualify for NotAllowedByListeners. However, I don't think this actually matters in practice, so conformance tests should not test behavior when a route is neither allowed by AllowedRoutes nor matches any Hostnames. Conformance tests for NotAllowedByListeners should probably omit Hostnames and tests for NoMatchingListenerHostname should probably omit AllowedRoutes (or rather, provide Listeners with compatible protocols and the implied AllowedRoutes.Kinds) from test Listeners as such.

[youngnick]

/lgtm