Implement InvalidKind reason for unknown/unsupported backendRef kind

[nathancoleman]

Changes proposed in this PR:

The contract for HTTPBackendRef has changed to include a new reason, InvalidKind, for the ResolvedRefs condition when an unknown or unsupported backendRef kind is used (docs). This change set implements that reason.

How I've tested this PR:

Created HTTPRoute w/ unknown/unsupported kind for backendRef, verifying that the new InvalidKind reason is assigned to the status.

Example

By making a small change to the backendRef on this HTTPRoute from the Learn guide:

apiVersion: gateway.networking.k8s.io/v1alpha2
kind: HTTPRoute
metadata:
  name: example-route-2
  namespace: consul
spec:
  parentRefs:
  - name: api-gateway
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /
    backendRefs:
    - kind: Nonsense
      name: nginx
      namespace: consul
      port: 80

How I expect reviewers to test this PR:

Checklist:

• Tests added
• CHANGELOG entry added

  Run make changelog-entry for guidance in authoring a changelog entry, and
  commit the resulting file, which should have a name matching your PR number.
  Entries should use imperative present tense (e.g. Add support for...)

[nathancoleman]

Debated adding e2e coverage for this, but it feels sorta like we're just duplicating upstream conformance tests. Thoughts?

[sarahalsmiller]

Debated adding e2e coverage for this, but it feels sorta like we're just duplicating upstream conformance tests. Thoughts?

If it's already covered in the upstream test, I don't see a reason to add an additional test.

[mikemorris]

We may want to hold off on merging this until a potential upstream spec conflict is resolved - I was reviewing upstream changes and the introduction of the InvalidKind RouteConditionReason in kubernetes-sigs/gateway-api#1243 seems to conflict with prior discussion in kubernetes-sigs/gateway-api#1155 (comment) which introduced a similar NotAllowedByListeners RouteConditionReason.

[mikemorris]

Skimmed the upstream changes too quickly - per discussion in Gateway API Slack it appears there's not actually a conflict, as InvalidKind is to be used only for an invalid BackendRef kind, whereas NotAllowedByListeners would be used on when the route kind (e.g. HTTPRoute) is not allowed by the listener AllowedRoutes config.

Separately from this change, we should likely open a draft PR updating the branch target for our conformance test fork (similar to #218) to check if the new tests added upstream in v0.5.0-rc2 are passing, or need to be skipped due to other issues we don't yet support (partial acceptance of routes, specific expected response codes). Checked and saw this was already updated over at kubernetes-sigs/gateway-api@main...hashicorp:gateway-api:conformance/v0.5.0-skipped-tests - I rebased to squash the subsequent changes back into fewer commits to keep our patch more manageable.