feat: honour JVM proxy system properties in reactive OAuth2 client

[chrisbonilla95]

Summary

The customWebClient used by Spring Security's reactive OAuth2 client for token exchange, userinfo, and refresh-token calls is built on Reactor Netty's HttpClient, which does not consult JVM proxy system properties by default. The JDK-based RestTemplate paths in this same library do consult them (ClientRegistrations.fromIssuerLocation for OIDC discovery, SimpleRemoteJwkSource for JWKS), creating a partial-proxy behaviour where OIDC discovery and JWKS calls go through a corporate proxy but token/userinfo/refresh calls silently bypass it.

Symptom for a customer behind a corporate egress proxy: the browser-side redirect to the IdP completes and credentials work, but the server-side callback (token exchange) hangs or 502s because the auth-service pod cannot reach the IdP's token endpoint directly.

Adding .proxyWithSystemProperties() to the HttpClient chain closes the gap. The call is a no-op when no proxy system properties are set, so customers who do not configure a proxy see no behaviour change.

What changed

• gooddata-server-oauth2-autoconfigure/src/main/kotlin/ReactiveCommunicationClientsConfiguration.kt:62-66 — one chained call on the HttpClient builder, plus a comment explaining the rationale.
• gooddata-server-oauth2-autoconfigure/src/test/kotlin/ReactiveCommunicationClientsConfigurationTest.kt — new unit test asserting both states (no proxy props ⇒ hasProxy() is false; https.proxyHost/https.proxyPort set ⇒ supplier-backed HTTP ProxyProvider matches host/port).

Test plan

• ./gradlew :gooddata-server-oauth2-autoconfigure:test — 261 tests pass (2 new, 259 pre-existing)
• ./gradlew :gooddata-server-oauth2-autoconfigure:detekt :gooddata-server-oauth2-autoconfigure:detektTest — clean
• Verified end-to-end against a real IdP behind a corporate proxy (cannot reproduce locally; recommend a consumer (gdc-nas auth-service) deploy and smoke-test login flow)

Notes on proxyProviderSupplier vs proxyProvider

Reactor Netty 1.2.x stores system-property-derived proxies as a Supplier<ProxyProvider> (lazy) on ClientTransportConfig, separate from the eager ProxyProvider field. hasProxy() is the right boolean check, since proxyProvider() alone returns null even when a supplier-backed proxy is configured. The test asserts against both to make this explicit.

Risk

risk: low — additive call that is a no-op for customers who do not set JVM proxy system properties. Behaviour for OIDC-only customers without a proxy is unchanged.

JIRA: TRIVIAL

[jeskepetr]

Looks good to me.
Thanks for the fix