Add nonProxyHosts to ProxyConfiguration

There isn't currently a way to specify non-proxy hosts for conjure generated clients. This is an FR to add a configuration field for explicitly configuring no-proxy hosts (separate from #3166, which would pull from environment)

Add a new nonProxyHosts field to ProxyConfiguration, and change ClientConfigurations to produce a new ProxySelector that matches on the provided non-proxy hosts in order to determine whether to indicate passthrough or proxy. Since the ProxySelector is passed through the Dialogue layer to the underlying hc clients, no modifications should be needed for https outside c-j-r and the associated api.

While this should be a straightforward change, there are a number of things to discuss:

• How should backcompat and rollout be handled? Since this is an additive change, it will not break compat with existing configuration. However, if a service were to have picked up non-proxy-hosts configuration via discovery and then roll back to a non-supported version, the proxy settings could either silently break or error out.
  • The first use cases will be with static non-proxy hosts that are introduced programmatically, which makes this a bit less of a concern.
• Should the nonProxyHosts be a List or a String?
  • Using a List would be less confusing for end users, and would elide discussion around whether the string should be delimited by commas (no_proxy envvar) or pipe characters (java).
• Should CIDR blocks be supported?
  • Initial implementation could just not support this and error out instead.
• Should domain suffix matching require explicit asterisks like in the Java case?
  • It would probably make more sense to make this behave more like the no-proxy envvar and suffix match even without wildcards.
• How should socks proxies and mesh be handled?
  • The best option might be to error out on configurations with a socks proxy or mesh is used with nonProxyHosts.

Some further investigation is required to determine how no-proxy will interact with Dialogue's custom DNS refreshing. Initial impression is that it should work with hostnames, but it probably won't work with IPs matching resolved hostnames (instead of other IPs), since the DNS resolution happens after the ProxySelector callback.

Start by locating ProxyConfiguration and ClientConfigurations, then trace how the ProxySelector passes through the Dialogue layer to the underlying HTTP clients. Review the existing proxy configuration and API behavior before resolving list format, matching rules, CIDR, SOCKS, mesh, and DNS-refresh interactions. Done means non-proxy hosts can be configured and matching requests bypass the proxy without breaking existing configurations.