s2a fix: don't check transport channel provider endpoint.

[rmehta19]

Certain handwritten client libraries set this field to the (TLS) endpoint via GrpcTransportOptions.setUpChannelProvider.

This isn't really a custom endpoint, so we should be able to use S2A when this is set.

Example with Cloud Logging: https://github.com/googleapis/java-logging/blob/644ebd756d44ffc02b58aa30d9a07c8afe700981/google-cloud-logging/src/main/java/com/google/cloud/logging/spi/v2/GrpcLoggingRpc.java#L137

[rmehta19]

@lqiu96 , would you be able to review this? Thanks!

[lqiu96]

Certain handwritten client libraries set this field to the (TLS) endpoint via GrpcTransportOptions.setUpChannelProvider.

I see, I wasn't aware of this use case. However, if a user does create their own TransportChannelProvider with a custom endpoint, then it wouldn't skip S2A.

Can you remind me again what the original rationale was for skipping a custom endpoint?

[rmehta19]

Can you remind me again what the original rationale was for skipping a custom endpoint?

When a user is setting a custom endpoint, we can't be sure this is a MTLS endpoint, therefore we can't use S2A. We only want to use S2A when we can use the MTLS endpoint.

However, if a user does create their own TransportChannelProvider with a custom endpoint, then it wouldn't skip S2A.

This is true, if a hw client library does this (say they set it to something foo.xyz.com) then S2A wouldn't get skipped, and S2A would be used to connect to MTLS endpoint of api (foo.mtls.googleapis.com) which isn't our desired behavior (we want to respect custom set endpoint and skip S2A in this case). Perhaps we could add some extra field (GAXProvidedEndpoint) to the TransportChannelProvider interface and GrpcTransportOptions.setUpChannelProvider can set that field instead? Then we could keep the S2A logic in EndpointContext as is. WDYT @lqiu96?

[rmehta19]

Friendly ping on this @lqiu96. Thank you!