Based upon discussion in https://docs.google.com/document/d/1gnsgfZVD_31ZG1eCYXpf0nSwYhBqVGQDebqjTQHetQs/edit# there is desire to align our forward looking efforts on ingress/egress to the gateway api. More than likely this will initially be towards using the istio mesh implementation supplied as a tech preview in recent openshift versions.

This epic will cover tasks such as:

1. coordinating with appropriate teams on the supportability of features need by RHOSAK - initially at least the gateway api and TLSRoutes, then features that allow for az specific configurations.
2. Validating the resource needs and performance characteristics of any on-cluster resources, including the operator and associated pods along with the proxies.
3. implementing support in the fleetshard operator - such as the configuration of the gateways for internal and external usage, and reporting of the necessary route from the load-balancer hostname rather than an ingresscontroller hostname.
4. in addition to or as an alternative to 2, coordinating with the strimzi team on built-in support
5. research on the alternative implementations should they become necessary due to support or cost considerations (envoy gateway, envoy contour, or whatever may be supplied as platoform specific - such as the eventual successor to the aws load balancer controller).