Add DockerProxy field for dynamic proxy configuration

[pablintino]

Add a new DockerProxy field to SystemContext that accepts a function for determining proxy URLs dynamically per request. This provides more flexibility than the static DockerProxyURL field, allowing for advanced proxy configurations such as those from httpproxy.Config.ProxyFunc().

[podmanbot]

✅ A new PR has been created in buildah to vendor these changes: containers/buildah#6627

[mtrmac]

Thanks for the PR. The implementation looks reasonable, but is it really necessary? The default behavior is net/http.ProxyFromEnvironment, which internally calls the same golang.org/x/net/http/httpproxy.

Certainly manual configuration of httpproxy.Config is not equivalent to reading from the environment, but … I think it would be pretty surprising for a proxy configuration of that kind to only apply to some references. Either registry.example needs a proxy or it doesn’t, I don’t see how using it for one operation and not using it for another makes much sense.

[pablintino]

Thanks for the PR. The implementation looks reasonable, but is it really necessary? The default behavior is net/http.ProxyFromEnvironment, which internally calls the same golang.org/x/net/http/httpproxy.

Certainly manual configuration of httpproxy.Config is not equivalent to reading from the environment, but … I think it would be pretty surprising for a proxy configuration of that kind to only apply to some references. Either registry.example needs a proxy or it doesn’t, I don’t see how using it for one operation and not using it for another makes much sense.

Thanks for the review @mtrmac . As we discussed offline, here is the context on why relying on http.ProxyFromEnvironment or creating a new context per request isn't viable for our use case:

• Performance & Context Reuse: We perform bulk image inspections in parallel. Building the SystemContext is expensive in our environment because it requires fetching certificates and pull secrets from the KubeAPI. To minimize overhead, we create a single context and reuse it across these bulk operations.

• Concurrency Safety: Since the application is multi-threaded and the proxy configuration is reconciled dynamically from a Kubernetes CR (the OpenShift Proxy config), modifying environment variables at runtime to satisfy ProxyFromEnvironment would be unsafe and lead to race conditions.

• Bootstrapping Constraints: This logic is also used during cluster bootstrapping (Day 0) via the Machine Config Operator. At this stage, the standard OpenShift environment variable injection isn't available yet, so we need a way to programmatically map the proxy configuration directly to the transport layer without relying on global state or fully deployed cluster mechanics.

This change allows us to bridge that gap safely.

[mtrmac]

Thanks!