Description of problem

The cluster-version operator currently looks to the hosted Kube API for egress configuration. But on hosted clusters, the cluster-version operator runs in a namespace on the management cluster, where it should be respecting management-cluster egress configuration, to avoid exposure to hosted-side configuration issues like:

Unable to retrieve available updates: Get "https://api.openshift.com/api/upgrades_info/v1/graph?arch=amd64&channel=stable-4.15&id=092b8ec1-67f7-4966-ac3c-e0336e1ab89b&version=4.15.14": proxyconnect tcp: dial tcp: lookup proxy.example.com on 172.30.0.10:53: no such host

which the management-cluster environment is failing to resolve.

Version-Release number of selected component

See on 4.15.14, but it's old, stable code, so possibly all hosted-cluster versions ever.

How reproducible

Every time.

Steps to Reproduce

1. Configure a proxy for the management cluster. Although I'm not terribly clear on how this happens, because these Proxy docs include: System-wide proxy affects system components only, not user workloads.
2. Configure a Proxy for the hosted cluster. Via HostedCluster's spec.configuration.proxy?
3. Check the ClusterVersion status to see how egress is being routed? Do we need to break egress to see the proxyconnect failure messages? Maybe there's something in CVO logs telling us which proxy is being configured.

Actual results

The cluster-version operator uses the hosted-cluster side Proxy configuration.

Expected results

The cluster-version operator should use the management-cluster-side proxy configuration.

Additional context

HyperShift tells us we're running a hosted cluster with --hypershift=true, which we could use to know when to ignore the hosted-Kube-API proxy configuration. Unclear to me at the moment what we should be looking at instead; I don't see HyperShift setting config.openshift.io/inject-proxy or directly setting HTTP_PROXY, HTTPS_PROXY, and NO_PROXY.