GH-577: Use JVM proxy settings in Netty client

[ennuite]

What's Changed

The Flight SQL JDBC driver ignored JVM proxy settings (-Dhttps.proxyHost, -Dhttps.proxyPort). Connections would always go directly to the target host, bypassing any configured proxy.

Switched to NettyChannelBuilder.forAddress(host, port) for the TCP-based schemes. This causes gRPC to go through ProxySelector, which picks up the standard JVM proxy properties.

Are these changes tested?

Yes.

Added a test to ConnectionTest that installs a recording ProxySelector as the JVM default, opens a JDBC connection, and asserts that ProxySelector.select() was called. This directly validates that the driver participates in JVM proxy detection without requiring a real proxy server.

This change was created with AI assistance (Claude Code). All lines were manually reviewed by a human. The output is not copyrightable subject matter.

Closes #577.

[jbonofre]

As I'm close to release Arrow Java 19.0.0, I will consider this PR for 20.0.0.

[ennuite]

@jbonofre yeah that makes sense, this one is still a draft as I have not finished work on it, I will ping you once I finish the PR. Should be ready in the next couple of days.

[ennuite]

While the fix was in the NettyClientBuilder, the bug report concerned the JDBC driver. Because of that, I targeted the test at the driver, ensuring that the whole connection creation flow did not bypass proxies.

Let me know if it's worth it to expand the testing surface with a unit test closer to the place of the bug fix.

[lidavidm]

Can we rebase? It seems CI did not trigger

[lidavidm]

It seems all workflows time out here, even after a retry.

[ennuite]

@lidavidm Thanks for the ping. I rebased all PRs.

[ennuite]

@lidavidm

It seems all workflows time out here, even after a retry.

Do you guys need help with the CI? I was going to look into some CI stuff on Arrow Go, but given that we have a release here I can jump in before I move to that.

Edit- I synced with JB and I saw that he is already on it. I'll continue with the protocol change implementation in other languages to have feature parity.

[lidavidm]

Well, other PRs are passing fine. Perhaps something in this PR may be related?

[jbonofre]

@ennuite @lidavidm I'm doing a new review on this one.

[ennuite]

@lidavidm you are right. @jbonofre the problem is in my code, it changes port validation and has the side effect of a bug in testUnencryptedConnectionProvidingInvalidPort.

I'm looking to fix this now.

[ennuite]

I tracked this down all the way to grpc-java and IMO the root cause is there, my change in this PR surfaced the problem.

The situation looks a bit involved. I can create some PRs in Arrow Java to gain some robustness over these lower level errors in time for this release, or we can leave this PR for a later release. I have no strong opinion either way, but I do have bandwidth to tackle at least one of these right now. If you are interested @lidavidm and @jbonofre let me know and I'll start work on this.

Improvements we could have in the JDBC driver:

• Port validation in the JDBC driver in the path of DriverManager.getConnection(): we could validate that the port is numeric and in the range [1, 65535]. This would fix the problem in the test and allow this PR to be merged. It is also quite easy to do.
• Liveness hardening on JDBC connection establishment: could honor the limits of DriverManager.setLoginTimeout(int) and properly implement DataSource.setLoginTimeout(int) and DataSource.getLoginTimeout(). This would not fix the bug in this test, but would allow users of the driver to have a way to prevent being blocked in the future by bugs that cause connection establishment to hang indefinitely.

Details about the root cause (no need to read this unless you're interested in the gRPC internals):

1- I changed the NettyChannelBuilder call from forAddress(SocketAddress) to forAddress(String, int). This allows us to respect JVM proxy settings and is the overload gRPC recommends for normal TCP channels.
2-An unintended side effect is that port validation moved from synchronous SocketAddress construction to asynchronous DNS resolution in a separate thread owned by gRPC.
3-If that asynchronous validation fails because of an invalid port, gRPC does not propagate the exception through the resolver listener. This causes testUnencryptedConnectionProvidingInvalidPort to hang indefinitely and CI to time out.

I will take this up with the gRPC folks and see if they agree that we need to propagate the exception there. In any case that will be too slow for this release.

[lidavidm]

Thanks for digging into it. I think we should do the validation here, and implement the timeout and follow up with grpc-java separately.

[ennuite]

@lidavidm I'll add the port validation in this PR later today. I think that makes sense as it both unblocks the PR and it is my change here that removed the fail-fast validation.

I created a couple issues for the JDBC connection timeouts: #1267 #1268 I'll grab them once I finish here, I already familiarized myself with the relevant code yesterday. I think it's fine to leave them for a later release though.

I'll also follow-up with gRPC (and try to provide a PR there if they agree that the problem is on their side).

Thanks for the guidance!