Flight-SQL JDBC driver ignores JVM proxy settings

[scruz-denodo]

Describe the enhancement requested

Hi, I was making some tests for checking the support of proxies with the Flight-SQL JDBC driver.

GRPC supports the JVM properties for indicating the default http proxy to use. Nevertheless, I tested with Flight-SQL JDBC driver without luck. The driver is ignoring them.
I mean these ones:
-Dhttps.proxyHost=<host> -Dhttps.proxyPort=<port>

Checking the reason, I arrived to these lines where the Netty channel is opened:

arrow-java/flight/flight-core/src/main/java/org/apache/arrow/flight/FlightClient.java

Lines 854 to 862 in bd2173c

	{
	builder = NettyChannelBuilder.forAddress(location.toSocketAddress());
	break;
	}
	case LocationSchemes.GRPC_DOMAIN_SOCKET:
	{
	// The implementation is platform-specific, so we have to find the classes at runtime
	builder = NettyChannelBuilder.forAddress(location.toSocketAddress());
	try {

Using method io.grpc.netty.NettyChannelBuilder#forAddress(java.net.SocketAddress) makes GRPC to create the channel using a direct connection to the host:port specified at connection uri, ignoring the proxy.
This happens on this code from ManagedChannelImplBuilder

  public ManagedChannelImplBuilder(SocketAddress directServerAddress, String authority,
      @Nullable ChannelCredentials channelCreds, @Nullable CallCredentials callCreds,
      ClientTransportFactoryBuilder clientTransportFactoryBuilder,
      @Nullable ChannelBuilderDefaultPortProvider channelBuilderDefaultPortProvider) {
    this.target = makeTargetStringForDirectAddress(directServerAddress);
    this.channelCredentials = channelCreds;
    this.callCredentials = callCreds;

I am not sure if there is a special reason for not opening the connection with the host and port values, instead of the java.net.SocketAddress:

builder = NettyChannelBuilder.forAddress(
                    location.getUri().getHost(), location.getUri().getPort());

But opening the channel in the previous way makes GRPC to follow the specified proxy at JVM properties.
-Dhttps.proxyHost=<host> -Dhttps.proxyPort=<port>

Could this be a valid enhancement request?