`URI::Generic#find_proxy` performs blocking DNS lookup before proxy selection

Net::HTTP#proxy_uri calls URI::Generic#find_proxy, which in turn calls IPSocket.getaddress on the destination hostname before deciding whether to route the request through the configured proxy. For some air-gapped deployments where hosts can only resolve public hostnames through the proxy (instead of e.g. via /etc/resolv.conf), the DNS lookup stalls for the OS DNS timeout (often 30+ seconds) when trying to perform any request via Net::Http.

We're considering a workaround for our Rails application at https://gitlab.com/gitlab-org/gitlab/-/merge_requests/245458. As we've noted before in https://about.gitlab.com/blog/we-need-to-talk-no-proxy/, wether no_proxy is checked before or after performing DNS lookups is inconsistent across languages and libraries, but as far as we can tell Net::HTTP is the outlier, whereas all other tools we checked did not perform a DNS lookup before checking against no_proxy (see specifically https://about.gitlab.com/blog/we-need-to-talk-no-proxy/#no_proxy-format. Note that Go is also listed there as resolving IP addresses, but it appears it does not perform DNS lookups. See https://gitlab.com/gitlab-org/gitlab/-/merge_requests/245458#note_3625951439).

Trace Net::HTTP#proxy_uri into URI::Generic#find_proxy, focusing on where IPSocket.getaddress runs relative to proxy and no_proxy selection. Reproduce the blocking lookup in an environment where the destination resolves only through the proxy, then verify that proxy selection no longer requires a direct DNS lookup first.