[Java][FlightSQL][JDBC] Driver drops TLS for endpoint locations advertised by the server

从 ArrowFlightSqlClientHandler.getStreams 开始，追踪已公布的 endpoint 位置如何配置克隆的客户端；检查 ClientHandshakeWrapper 以了解观察到的握手路径。使用 withEncryption(true)、credentials 和一个不安全的 FlightInfo endpoint 重现问题，然后添加回归覆盖，证明已配置的加密要求不会被静默丢失，并且 credentials 不会通过明文发送。

When a query result has endpoints with non-empty locations, ArrowFlightSqlClientHandler.getStreams clones the connection's Builder and connects to each advertised location. The clone keeps username/password, token and the OAuth config, and encryption is then set from the location scheme alone:

.withEncryption(endpointUri.getScheme().equals(LocationSchemes.GRPC_TLS))

So a location with any other scheme (grpc+tcp:// in particular) turns encryption off for that endpoint client even when the connection was opened with useEncryption=true. build() then runs the handshake and sends the credentials over the plaintext channel to the advertised host.

The documented meaning of useEncryption (default true) is "Whether to use TLS (the default is an encrypted connection)", so a server-supplied string silently overriding it is surprising: a compromised or hostile Flight SQL server, or anything able to influence the FlightInfo it returns, can have the driver hand over the user's credentials in cleartext, and a passive attacker on the endpoint path can read them.

Reproduced against a handler built with withEncryption(true) plus a username/password, given a FlightInfo with one endpoint at Location.forGrpcInsecure(...): the driver attempts the connection and reaches ClientHandshakeWrapper on the unencrypted channel instead of refusing it.

arrow-flight-sql-jdbc-driver, main.