update AdvancedTlsX509KeyManager to support key alias for reloaded cert

[zhangweikop]

Overview

Make the alias in AdvancedTlsX509KeyManager dynamic so it can be used with Netty's
OpenSslCachingX509KeyManagerFactory to update key material after reload.

Fixes #12670

Problem

When using SslProvider.OPENSSL, each TLS handshake must encode Java key material into a native
buffer consumed by OpenSSL, which can account for ~8% of server CPU. Netty's
OpenSslCachingX509KeyManagerFactory avoids this by caching the encoded buffer keyed by alias —
but the previous implementation always returned "default", so the factory could never detect
credential rotations and create a new cache entry on cert reload.

Details

• The alias is now set to key-<N> (e.g. key-1, key-2, ...) and incremented on every
  updateIdentityCredentials call, ensuring the same alias always maps to the same key material.
• A new constructor AdvancedTlsX509KeyManager(int revisionWarningThreshold) allows customizing
  the soft warning threshold (default: 1024, matching OpenSslCachingX509KeyManagerFactory's
  default maxCachedEntries). A warning is logged when the counter reaches the threshold, since
  beyond that point new aliases won't be cached and per-handshake encoding overhead resumes. The
  key manager remains fully functional past this threshold.
• All alias methods return null before any credentials are loaded.
• Recommended usage with OpenSSL:

new OpenSslCachingX509KeyManagerFactory(
    new KeyManagerFactoryWrapper(advancedTlsKeyManager))

[ejona86]

I don't think using AdvancedTlsX509KeyManager with OpenSslCachingKeyMaterialProvider is all that good an approach with this, because it essentially leaks all prior keys in memory. If the life of the process after a year has 5 versions, that's not that big of a deal. But if it changes ever hour, that's not good. I don't think we're going to put random detection code in AdvancedTlsX509KeyManager to just warn you that things have gone wrong either.

[zhangweikop]

I don't think using AdvancedTlsX509KeyManager with OpenSslCachingKeyMaterialProvider is all that good an approach with this, because it essentially leaks all prior keys in memory. If the life of the process after a year has 5 versions, that's not that big of a deal. But if it changes ever hour, that's not good. I don't think we're going to put random detection code in AdvancedTlsX509KeyManager to just warn you that things have gone wrong either.

Yes, I think it should be used with caution.
In our case, the PKI-issued certificates have a relatively long lifetime, so over the application process’s three-month lifecycle, reloads occur only a few times.
To support users who require more frequent key rotation, Netty's OpenSslCachingKeyMaterialProvider would need to remove old keys.

As for AdvancedTlsX509KeyManager itself, I think we still need to handle alias changes?