[improve][misc] Improve AES-GCM cipher performance

[ocadaruma]

Fixes #23121

Motivation

• Java Pulsar client uses BouncyCastleProvider for AES-GCM encryption, which is known to be slow due to the lack of hardware instruction optimization.
• See Encryption performance improvement on Java client #23121 for the detailed benchmark result

Modifications

• Modify MessageCryptoBc to use SunJCE provider which comes with hardware-instruction optimization instead of BouncyCastle provider.

Verifying this change

• Make sure that the change passes the CI checks.

This change is already covered by existing tests, such as org.apache.pulsar.tests.integration.SimpleProducerConsumerTest

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

If the box was checked, please highlight the changes

• 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

Documentation

• doc
• doc-required
• doc-not-needed
• doc-complete

Matching PR in forked repository

PR in forked repository: Pulsar CI workflow run result

[lhotari]

Thanks for the contribution @ocadaruma!
The only concern I have about the change is the users of Pulsar that require FIPS compliant encryption. Pulsar has docs about enabling BouncyCastle's FIPS library in https://pulsar.apache.org/docs/3.3.x/security-bouncy-castle/. It's seems when the FIPS library is enabled, the SunJCE provider shouldn't be made the default. I'll add a suggestion about how to achieve this.

UPDATE: The previous solution has already ignored the presence of BouncyCastleFipsProvider, so I think that the changes in this PR are fine. The issue in FIPS compliance is a separate issue.

[lhotari]

LGTM

[ocadaruma]

@lhotari Agree.
Currently MessageCryptoBc anyways uses hardcoded BC so we should ifx it to load bc fips provider as necessary and this PR isn't harmful.