Context:
Control plane ingress for HCP has become a collection of inconsistent, arbitrary choices, making it difficult to use, maintain, and introduce changes without risking breaking existing clusters.

UX problem:
The API allows for more flexibility than is actually supported via
https://github.com/openshift/hypershift/blob/main/api/hypershift/v1beta1/aws.go#L323-L326
https://github.com/openshift/hypershift/blob/main/api/hypershift/v1beta1/hostedcluster_types.go#L660

• Some examples of unpredictable behaviour:
  1 - When you are in somehow private topology, publishingStrategy.routes.hostname doesn't impact internal hostnames (hypershift.local) expect for ignition, where we prefer publishingStrategy.routes.hostname over .local. The host on the route will have .local. but we use status.ignitionEndpoint (with routes.hostname) to generate the userdata secret so machines will boot through that

2 - When you are in publicAndPrivate the input for konnectivity route.hostname is ignored.

3 - tbd.

The introduction of shared ingress and swift for aro exacerbates this problem causing the configuration matrix to grow exponentially.

Implementation problem:
The code executing these paths has become unsustainable and lacks proper testing.

Success criteria:

• UX
  Document supported configurations.
  Forbid unsupported configurations in the API via CEL validation
  Leverage ratcheting (default for >=1.33) to avoid breaking existing "invalid" configurations.

• Implementation
  All supported API configurations have strong unit test coverage
  All tests outputs can be seen as a single cohesive collection of manifests (Services, Pods and routes) for each test scenario for all platforms.