feat(gateway-api): add destination port matching GEP-957

[pmalek]

What this PR does / why we need it:

This PR aims to implement GEP-957: Destination Port Matching

Which issue this PR fixes:

Fixes #2709

Special notes for your reviewer:

• Which Accepted reason to use:

  For now, the routes that will end up not being attached to a Gateway because of unmet port criteria (missing listener in the Gateway with the specified Port) will get an Accepted condition with NoMatchingListenerHostname reason.

  This should be addressed also in this PR IMHO and the proposed course of action is:

  - use a const defined in our codebase
  - submit an issue with the above described proposal to https://github.com/kubernetes-sigs/gateway-api/
  - swap the self defined const with the one defined in upstream whenever (if) it gets released there.

  The above has been mitigated for now with RouteReasonNoMatchingListenerPort which has been defined in our codebase.

• Open question: since only HTTPRoute was graduated in beta would it be fine to add tests just for that route type and leave the other ones without (while tracking that in a separate issue: to add whenever they graduate to beta)?

• I also added a call to r.DataplaneClient.DeleteObject(httproute) when the route "is not accepted". This way I was able to get the route to get pruned after changing a parent ref port which wouldn't match the Gateway. I believe that's the way it should be but I can be proven wrong.

PR Readiness Checklist:

Complete these before marking the PR as ready to review:

• the CHANGELOG.md release notes have been updated to reflect any significant (and particularly user-facing) changes introduced by this PR
• add integration tests for this change for
  • HTTPRoute

[rainest]

Deleting from the store is the same thing #3119 does, with the same caveat as its notes. It's a break from what we've been doing, but I think it is probably what we should be doing.

One issue with test logging and testify not providing the tools we need to report issues concisely. Implementation looks fine.

[rainest]

Open question: since only HTTPRoute was graduated in beta would it be fine to add tests just for that route type and leave the other ones without (while tracking that in a separate issue: to add whenever they graduate to beta)?

In general, since we do have implementations of the other route types and do test with our alpha flag on, I'd say apply like changes to all unless we expect something to change (if there's an existing GEP or an area of the spec we know is incomplete). Here we should have reasonable confidence that the other route types can (or always will) have ports and will bind to Listeners with those ports, so we could proceed with adding the rest of these immediately.

[pmalek]

Open question: since only HTTPRoute was graduated in beta would it be fine to add tests just for that route type and leave the other ones without (while tracking that in a separate issue: to add whenever they graduate to beta)?

In general, since we do have implementations of the other route types and do test with our alpha flag on, I'd say apply like changes to all unless we expect something to change (if there's an existing GEP or an area of the spec we know is incomplete). Here we should have reasonable confidence that the other route types can (or always will) have ports and will bind to Listeners with those ports, so we could proceed with adding the rest of these immediately.

Good, in such case I'll leave #2709 open for that purpose.