Revert #3400: Reintroduce experimental S2A integration in client libraries grpc transport

[rmehta19]

Revert #3400.

This PR re-introduces the S2A integration the Java Cloud SDK (initially introduced in #3326, and temporarily reverted in #3400).

This PR does this by reverting #3400 with the following patches:

• load the S2A APIs via reflection. This allows us to merge the code while the S2A API is still experimental in gRPC-Java without introducing a diamond dependency conflict. Once the S2A APIs are stable, the reflection logic can be removed and the S2A API can be used directly (via a dependency on S2A API)
• fix NPE (s2a fix: fix NPE. #3401)
• plumb mTLSEndpoint (fix: plumb mtlsEndpoint to gRPC Channel provider instead of setting it in EndpointContext. #3386)
• use a different env var name for enabling the feature

Below is the original description from #3326

Modify the Client Libraries gRPC Channel builder to use mTLS via S2A if the experimental environment variable is set, S2A is available (We check this by using SecureSessionAgent utility), and a few more conditions (see shouldUseS2A).

Following https://google.aip.dev/auth/4115, Only attempt to use S2A after DirectPath and DCA (https://google.aip.dev/auth/4114) are ruled out as options. If conditions to use S2A are not met (env variable not set, or S2A is not running in environment, etc (shouldUseS2A returns false)), fall back to default TLS connection.

When we are creating S2A-enabled Grpc Channel Credentials, we first try to secure the connection between the client and the S2A via MTLS, using MTLS-MDS credentials. If MTLS-MDS credentials can't be loaded, then we fallback to a plaintext connection between the client and S2A.

The parallel go implementation : googleapis/google-api-go-client#1874 (now lives here: https://github.com/googleapis/google-cloud-go/blob/main/auth/internal/transport/cba.go)

S2A Java client: https://github.com/grpc/grpc-java/tree/master/s2a

Resolving b/376258193 means that S2A.java is no longer experimental

[rmehta19]

Looks like running mvn fmt:format resulted in all these changes. Perhaps these changes could be made in another PR and then can be removed from this PR.

[zhumin8]

Looks like these are missed in #3513.
We will do a separate PR for these and you can remove from this PR

[rmehta19]

Thanks! with the latest merge of main, these changes have been removed from this PR.

[rmehta19]

@lqiu96 @blakeli0 @zhumin8 , please review, thanks!

[xmenxk]

nit: this can be one line.

[xmenxk]

There was a issue raised re: netty-tcnative dropping support for Windows and MacOS Intel platforms, do we want to add the runtime checks here an skip S2A if the code is running on an unsupported platforms?

We can also do that in a followup PR, but just to mention it here so we don't forget.

[xmenxk]

I assume this is what we discussed re: only pick the mtls endpoint when we know s2a will be used and directpath will not be used, but let know if otherwise. thanks

[rmehta19]

Yes this is correct. Removed the logic in determineEndpoint in EndpointContext to set the mtls endpoint if shouldUseS2A returns true. Plumb down the mtls endpoint so that we use it only when we know DirectPath is not being used.

This is because the decision to use S2A and the decision to use DirectPath happen in different places (EndpointContext vs InstantiatingGrpcChannelProvider).