core: Handle ProxySelector IllegalArgumentException

[kkmurthyt21]

Fixes #13052.

Android’s DefaultProxySelector.select() may throw IllegalArgumentException when the system proxy configuration contains an invalid port. This unchecked exception currently escapes the DNS resolver task and can terminate the process.

This change catches the exception at the ProxySelector.select() call and wraps it in an IOException. The original cause is preserved, and the exception message identifies the ProxySelector implementation.

DnsNameResolver already handles an IOException from proxy detection as an UNAVAILABLE name-resolution result. This allows the resolver to fail cleanly instead of letting the unchecked exception escape.

This intentionally avoids silently falling back to a direct connection. It follows the fail-cleanly approach used for invalid ProxySelector results in #12793 and avoids bypassing a configured proxy.

Testing

1. Added a regression test verifying that the exception is wrapped, the original cause is preserved, and the ProxySelector implementation is identified.
2. Ran .\gradlew.bat :grpc-core:test --tests "io.grpc.internal.ProxyDetectorImplTest"
3. All 11 tests passed on Windows with Temurin JDK 17.

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: kkmurthyt21 / name: Krishna Kandi (bc01614)

[AgraVator]

Thanks for picking this up. Approach is right, a few things need changing.

The test doesn't cover the actual bug. ProxyDetectorImpl throwing IOException was already
handled before this PR the crash is the unchecked exception escaping DnsNameResolver$Resolve.run()
onto the executor thread. As written the test passes on a build that still crashes. There's a
pattern to copy in DnsNameResolverTest around L519 (thenThrow(new IOException())); the same with
an IllegalArgumentException, asserting the listener gets a result, fails on master today.

Related: select() isn't the only unguarded call on that path. A few lines down
requestPasswordAuthentication() lands in java.net.Authenticator, which apps install via
setDefault() same thread, same crash. So this also wants a catch around detectProxy() in
Resolve.run() converting unchecked to IOException, and I'd widen the catch here to
RuntimeException rather than just IAE.

Also worth knowing: the message you're building never reaches the user, because DnsNameResolver
overrides the description with "Unable to resolve host " + host. I've argued for falling back to
no-proxy on the issue instead probably worth waiting for that to settle before reworking, no point
doing it twice.

[AgraVator]

Nit: assertSame for the cause.

[kkmurthyt21]

Thanks for taking a close look. This is helpful. I agree that a resolver level test would better cover the actual failure path, and I will change the cause check to assertSame.

Before I rework the implementation, could one of the maintainers confirm the preferred behavior? Should this fall back to a direct connection, or return UNAVAILABLE? Also, should the broader RuntimeException handling be placed around detectProxy() in DnsNameResolver?

Once that is confirmed, I will update the implementation.