After RHCLOUD-29908, all OCM backends are getting auth headers.  This broke some minor functionality in stage and production (we didn't notice it in time).

The injection includes Cincinnati backend serving under /api/upgrades_info/v1, which serves public data (at least the endpoint OCM is using), doesn't need auth.

Unfortunately, while it supports CORS, it's set up to reject CORS preflight when given Authorization, which is what happens now:

> curl -i --insecure -X 'OPTIONS' -H 'access-control-request-method: GET' -H 'origin: https://console.redhat.com' -H 'access-control-request-headers: authorization' 'https://api.openshift.com/api/upgrades_info/v1/graph?channel=stable-4.14'
HTTP/2 400 
content-length: 43
date: Thu, 11 Jan 2024 11:56:18 GMT
set-cookie: 609f91be912da47026eb733a4b0de2df=13880a3832433d7d1f63c1ae6e2e0d74; path=/; HttpOnly; Secure; SameSite=None
x-envoy-upstream-service-time: 2
server: envoy

One or more request headers are not allowed

Whether that's ideal CORS config is still in discussion, but arguably it prevents us from sending credentials that server doesn't need.
The correct fix from UI side is not send Authorization header.

Known symptom — Releases page

1. Visit https://console.redhat.com/openshift/releases
2. Note "Latest version" number (and link to release notes) don't show.

expected behavior (before)	actual behavior

Also, Network tab shows CORS errors:

Unknown symptom — ROSA wizard

1. Visit https://console.redhat.com/openshift/create/rosa/wizard
2. Click Next button to proceed to "Accounts and roles" step.
3. (might depend on user's organization and linked aws accounts?)
   Normally, same request is made here and fails due to CORS.
   

We're not certain yet how severe this is.
(Looks like `latestVersionLoaded` will remain false, and some version compatibility warnings might not be shown, potentially allowing user to proceed with installation which will fail?)

Requested fix

• If faster, consider first reverting the change in prod.  (staging matters less)
• The current logic checking domains is not enough, because api.openshift.com domain hosts multiple backends, and we need to opt-out specific path.
  Hardcode in insights-chrome exclusion of requests starting with /api/upgrades_info ?
• It might be better to let our app decide which requests to opt-out.
  E.g. if we pass fake "X-HCC-Authorization: false" header, strip it and don't inject auth ?

Additional info

Out of scope to immediate issue, but the domains 'https://api.openshift.com', 'https://api.stage.openshift.com' allow-listed in
https://github.com/RedHatInsights/insights-chrome/blob/5828ac1cb27c76fe97338caed1bb13402a914794/src/utils/iqeEnablement.ts#L13
are not enough anyway — we also have environments api.integration.openshift.com, api.int.openshiftusgov.com, api.apps.ssotest01ue1.a7a5.p1.openshiftapps.com
and expect to add many more for XCM effort.

Therefore, it will become better to let our app decide which domains/requests to opt-in. 

• Again, can be done by fake header?  (We already had code on our side adding token to most requests; switching it to a static fake header will be easy but still a win as insights-chrome will manage up-to-date token).
• Or some useChrome API to register domains/paths ?