[improve][client] Make client TLS/crypto helpers work on FIPS-restricted JVMs

[david-streamlio]

Motivation

Two client-path helpers hardcode SUN-provider-specific choices that fail or fall back to non-approved crypto on JVMs running a restricted security configuration (e.g. BC-FIPS in approved-only mode):

1. MessageCryptoBc pins SecureRandom.getInstance("NativePRNGNonBlocking") for data-key and GCM-IV generation. That algorithm doesn't exist in FIPS providers, and even when the fallback engages, randomness is sourced outside the FIPS-validated module. NIST SP 800-38D permits random 96-bit GCM IVs only when generated by an approved DRBG.
2. KeyManagerProxy (the auto-refreshing PEM key manager) hardcodes KeyStore.getInstance("JKS") for its in-memory keystore, which fails where the JKS keystore type is unavailable.

This is one of a set of small preparatory cleanups for FIPS-restricted deployments; a broader PIP is being drafted separately.

Modifications

• MessageCryptoBc: when a BCFIPS provider is registered, obtain SecureRandom.getInstance("DEFAULT", bcfips) — the BC-FIPS SP 800-90A DRBG — so key/IV generation stays within the FIPS-validated module. Only registered providers are consulted (Security.getProvider), deliberately avoiding BouncyCastle classpath resolution during class loading, consistent with the existing lazy BcProviderHolder design. Behavior on standard JVMs is unchanged (NativePRNGNonBlocking, falling back to new SecureRandom()).
• KeyManagerProxy: keep JKS as the preferred in-memory keystore type, but fall back to KeyStore.getDefaultType() when JKS is unavailable. JKS remains preferred deliberately: PKCS12's setKeyEntry rejects certificate lists that do not form a linked chain, which JKS accepts — switching unconditionally to the default type breaks KeyManagerProxyTest's multiple-CA case (verified while developing this change).

Verifying this change

• Make sure that the change passes the CI checks.

This change is already covered by existing tests: KeyManagerProxyTest (including the multiple-CA chain case that pins the JKS-preferred behavior) and RawBatchMessageContainerImplTest (exercises MessageCryptoBc encryption end-to-end). The BCFIPS branch cannot be exercised without a FIPS-registered JVM; it is compile-verified, and the DEFAULT SecureRandom service is confirmed present in bc-fips 2.0.1.

Does this pull request potentially affect one of the following parts:

• Dependencies (add or upgrade a dependency)
• The public API
• The schema
• The default values of configurations
• The threading model
• The binary protocol
• The REST endpoints
• The admin CLI options
• The metrics
• Anything that affects deployment

[Copilot]

Pull request overview

This PR improves Pulsar client-side TLS/crypto helper compatibility with FIPS-restricted JVM security configurations by avoiding hardcoded SUN-provider assumptions and selecting FIPS-appropriate primitives when the BC-FIPS provider is registered.

Changes:

• MessageCryptoBc: Prefer SecureRandom from the registered BCFIPS provider (its DRBG) when available; otherwise keep existing NativePRNGNonBlocking behavior.
• KeyManagerProxy: Prefer JKS for the in-memory keystore but fall back to KeyStore.getDefaultType() when JKS is unavailable (e.g., under FIPS restrictions).

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
pulsar-common/src/main/java/org/apache/pulsar/common/util/KeyManagerProxy.java	Adds JKS → default keystore-type fallback for the in-memory keystore used by the auto-refreshing PEM key manager.
pulsar-client-messagecrypto-bc/src/main/java/org/apache/pulsar/client/impl/crypto/MessageCryptoBc.java	Switches SecureRandom selection to use BC-FIPS DRBG when BCFIPS is registered, preserving non-FIPS behavior otherwise.