api: add RouteConditionReason to v1alpha2

[mikemorris]

What type of PR is this?
/kind documentation
/kind feature
/kind api-change
/kind deprecation

What this PR does / why we need it:

Adds a RouteConditionReason type with known required reasons and renames two RouteConditionType constants. Not sure if the release note formatting would make more sense to split this into two separate PRs.

Which issue(s) this PR fixes:

Fixes #1109, refs #1112

Does this PR introduce a user-facing change?:

adds RouteConditionReason type with RouteReasonAccepted, RouteReasonResolvedRefs and RouteReasonRefNotPermitted constants

deprecates ConditionRouteAccepted and ConditionRouteResolvedRefs constants, adds RouteConditionAccepted and RouteConditionResolvedRefs constants

[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.

[rainest]

In the course of writing our Gateway.Listeners[].allowedRoutes implementation @shaneutt noted that there was no way we could indicate rejections on the resource. He originally suggested a ConditionRouteRejected in line with the existing constants, but assuming this is accepted it looks like we should instead add a false RouteConditionReason for RouteConditionAccepted.

Not sure if we could piggyback off this PR to do so; I submitted mikemorris#1 if so, or can retarget it to this repo after this is merged.

[mikemorris]

Agreed that's a valid case that's difficult to communicate currently @rainest, and I do think communicating this through a RouteConditionReason feels safer than crossing a disallowed namespace boundary to set a ListenerStatus condition (the not accepted case I wrote up in #1112 basically describes the same need you identified!)

I think I'd lean towards retargeting after merging this though given that it's somewhat new/unspecified scope - might be nice to add a conformance test (or augment the existing HTTPInvalidCrossNamespace test) illustrating expected usage too.

[robscott]

@mikemorris A few tiny comments but otherwise LGTM. @rainest I like the change you proposed in mikemorris#1, do you mind filing a follow up PR here once this one merges?

[robscott]

/ok-to-test

[robscott]

Found one more very tiny nit, but does not need to block.

/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

[robscott]

/lgtm