Description of problem:

    Public HCP cluster using cluster wide proxy results in console pods unable to start, other systems do not work accurately (ingress controller operator in degraded state)

Version-Release number of selected component (if applicable):

    4.16.X, 4.17.X

How reproducible:

    Always

Steps to Reproduce:

    1. Make a public HCP cluster with cluster-wide-proxy set
    2. Cluster console pods will not start with an error similar to:

`failed to construct oauth endpoint cache`    

Actual results:

    Cluster does not come up correctly

Expected results:

    Cluster comes up correctly

Additional info:

• An HCP Cluster forces the $cluster_id.p3.openshiftapps.com to be added to the NOPROXY settings, which means that `api.$cluster_name.$cluster_id.p3.openshiftapps.com` will never correctly route through the proxy. This means that the console pods cannot communicate with api.$cluster_name.p3.openshiftapps.com and thus crash
• The console seems to always use `api.$cluster_name.$cluster_id.p3.openshiftapps.com`, if it instead used `api.$cluster_name.hypershift.local` it's possible this would resolve the issue.
• Communication that occurs via `api.$cluster_name.hypershift.local` (like that of the OVNKubernetes pods) continues to work correctly.

 
Potential Fix: * Either route console traffic via the api.$cluster_name.hypershift.local service endpoint, or, allow an override for this to work with a proxy.

 
Workarounds attempted: * Putting the cluster into private mode seems to allow this to work, but as soon as you move it back to public mode it will stop working again.

Hypothesis: we have not yet experienced a customer who would like both a public HCP cluster that also wants a proxy, which may mean we haven't tested this combination.