[feat gw-api]handle hostname intersection

[shuqz]

Description

we were not properly handle case when listener has hostname but route does not, therefore failing conformance test - HTTPRouteListenerHostnameMatching
This implementation covers this gap by

• setting compatible hostname during route attachment
• use compatible in listener builder phase

Checklist

• Added tests that cover your change (if possible)
• Added/modified documentation as required (such as the README.md, or the docs directory)
• Manually tested

re-run HTTPRouteListenerHostnameMatching and got

    --- PASS: TestConformance/HTTPRouteListenerHostnameMatching (245.50s)
        --- PASS: TestConformance/HTTPRouteListenerHostnameMatching/6_request_to_'foo.com/'_should_receive_one_of_[] (0.13s)
        --- PASS: TestConformance/HTTPRouteListenerHostnameMatching/2_request_to_'baz.bar.com/'_should_go_to_infra-backend-v3 (0.13s)
        --- PASS: TestConformance/HTTPRouteListenerHostnameMatching/7_request_to_'no.matching.host/'_should_receive_one_of_[] (0.14s)
        --- PASS: TestConformance/HTTPRouteListenerHostnameMatching/3_request_to_'boo.bar.com/'_should_go_to_infra-backend-v3 (0.15s)
        --- PASS: TestConformance/HTTPRouteListenerHostnameMatching/5_request_to_'multiple.prefixes.foo.com/'_should_go_to_infra-backend-v3 (0.15s)
        --- PASS: TestConformance/HTTPRouteListenerHostnameMatching/1_request_to_'foo.bar.com/'_should_go_to_infra-backend-v2 (0.15s)
        --- PASS: TestConformance/HTTPRouteListenerHostnameMatching/0_request_to_'bar.com/'_should_go_to_infra-backend-v1 (0.15s)
        --- PASS: TestConformance/HTTPRouteListenerHostnameMatching/4_request_to_'multiple.prefixes.bar.com/'_should_go_to_infra-backend-v3 (0.15s)

• Made sure the title of the PR is a good description that can go into the release notes

BONUS POINTS checklist: complete for good vibes and maybe prizes?! 🤯

• Backfilled missing tests for code in same general area 🎉
• Refactored something and made the world a better place 🌟

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: shuqz
Once this PR has been reviewed and has the lgtm label, please assign zac-nixon for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

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

[shuqz]

/retest

[zac-nixon]

It would be great to add a comment saying what a "compatible hostname" is.

[zac-nixon]

From gateway documentation,

Hostnames defines a set of SNI names that should match against the
SNI attribute of TLS ClientHello message in TLS handshake. This matches
the RFC 1123 definition of a hostname with 2 notable exceptions:
1. IPs are not allowed in SNI names per RFC 6066.
2. A hostname may be prefixed with a wildcard label (*.). The wildcard
label must appear by itself as the first label.
If a hostname is specified by both the Listener and TLSRoute, there
must be at least one intersecting hostname for the TLSRoute to be
attached to the Listener. For example:
A Listener with test.example.com as the hostname matches TLSRoutes
that have either not specified any hostnames, or have specified at
least one of test.example.com or *.example.com.
A Listener with *.example.com as the hostname matches TLSRoutes
that have either not specified any hostnames or have specified at least
one hostname that matches the Listener hostname. For example,
test.example.com and *.example.com would both match. On the other
hand, example.com and test.example.net would not match.
If both the Listener and TLSRoute have specified hostnames, any
TLSRoute hostnames that do not match the Listener hostname MUST be
ignored. For example, if a Listener specified *.example.com, and the
TLSRoute specified test.example.com and test.example.net,
test.example.net must not be considered for a match.
If both the Listener and TLSRoute have specified hostnames, and none
match with the criteria above, then the TLSRoute is not accepted. The
implementation must raise an 'Accepted' Condition with a status of
False in the corresponding RouteParentStatus.

[zac-nixon]

How does this work for a route that attaches to two different listeners in a Gateway?

[zac-nixon]

Don't we need a nil check still?