Refactor OIDC Client and Header Handling for Secure Profile when an ADC or reverse proxy is present

[challamani-ms]

Currently, the Calm-Hub project packages both the UI and backend as a single instance (exposed on a single port) with a secure Quarkus profile enabled. When the backend runs in secure mode, authentication, authorization, and service-side TLS are enabled.

The UI uses an OIDC-client for login. This setup works correctly when no ADC (Application Delivery Controller) or reverse proxy is involved, as the code manually sets the Authorization header with a Bearer token.

However, when an ADC or reverse proxy is present, requests are being rejected because:

• Even when the UI runs with HTTPS, the request still includes an Authorization header with an empty value (alongside the Bearer token header), due to oidc-client initialization failure when ADC presents.
• Some proxies reject requests that include empty or conflicting authorization headers.

Proposed Changes:

• Refactor header handling in calm-hub-ui
• Ensure the Authorization header is only set when a valid token exists.
• Avoid sending empty Authorization headers that cause issues in proxy or ADC environments.
• Introduce an explicit configuration flag to enable or disable the OIDC client (instead of inferring behavior from the HTTPS protocol).
• In the case of ADC/reverse-proxy, calm-hub-ui has to be configured with OIDC client disabled.

Expected Outcome

• Seamless operation in environments with or without ADC/reverse proxies.
• Cleaner request headers with no empty or redundant Authorization values.

[challamani-ms]

Code Changes are approved and merged - #1780