fix(runtime): HTTPClient configs now propagate to loaders + loader funcs

[philipaconrad]

What changed, and why?

An HTTPClient.Configuration passed to OPA.Runtime.init never reached the bundle loaders. The Runtime stored it, but constructed every loader with httpClientConfig: nil, so each loader fell back to the global default config.

We now propagate any provided config down to all bundle loaders, including the discovery bundler loader.

We also now support HTTP config provider closure functions, which can be used to dynamically provide a correct HTTPClient configuration or TLSConfig on each load() call. This is anticipated to make certificate rotation easier to implement for advanced users.

The HTTPClientConfigSource enum is used to select between different ways that the config should be acquired, and only the nil/fixed config cases can TLS settings be overridden by the OPA config:

• nil (none): Config file owns TLS. credentials.client_tls builds it on top of the global default http client config.
• .fixed(cfg): Config file owns TLS if credentials.client_tls is set. Without client_tls, the fixed config is used verbatim.
• .tls(provider): Provider owns TLS.
• .configuration(provider): Provider owns everything. Nothing from the OPA config is used.

Note: For services using default/bearer/oauth2 credentials the loader never consults services[_].tls, so an injected configuration is currently the only way to configure TLS for them.

How to test

• New tests should be picked up automatically by CI.

Related Resources