Performance overhead on handshake when using `AdvancedTlsX509KeyManager` with OPENSSL provider

[zhangweikop]

Is your feature request related to a problem?

When using AdvancedTlsX509KeyManager with SslProvider.OPENSSL, each TLS handshake must
encode the Java key material into a native buffer consumed by OpenSSL when access key material (see
ReferenceCountedOpenSslContext).
In our cases, profiling shows accounts for up to ~8% of gRPC server CPU in handshake-heavy scenarios(e.g. when the gRPC server restarts and many connections are re-established).

Describe the solution you'd like

Use a dynamic alias that updates on each credential load, so the key manager can be safely
wrapped by OpenSslCachingX509KeyManagerFactory.
The proposed change is like:
master...zhangweikop:grpc-java:tls-key-manager-update
Such change enables wrapping the key manager with OpenSslCachingX509KeyManagerFactory, which caches the encoded
key material buffer and reuses it across handshakes.
Local testing shows significant improvement with such changes applied.

Describe alternatives you've considered

Make the change in Netty to make OpenSslCachingX509KeyManagerFactory and support auto reloading somehow.

Additional context

With the proposed update, the key manager can be used with OpenSslCachingX509KeyManagerFactory as follows:

AdvancedTlsX509KeyManager keyManager = new AdvancedTlsX509KeyManager();
keyManager.updateIdentityCredentials(certFile, keyFile, 10, TimeUnit.MINUTES, executor);

KeyManagerFactory kmf = new OpenSslCachingX509KeyManagerFactory(
    new KeyManagerFactoryWrapper(keyManager));

SslContext sslContext = GrpcSslContexts.configure(
    SslContextBuilder.forServer(kmf), SslProvider.OPENSSL)...