Make IPrivateKeyDecryptor Instantiation Configurable in JWTEncryptionPreferences to avoid compilation-time errors

[P1car00n]

Is your feature request related to a problem? Please describe.

The class JWTEncryptionPreferences has a private IPrivateKeyDecryptor field (privateKeyDecryptor) that is instantiated immediately with BCPrivateKeyDecryptor(). Although it is possible to override the IPrivateKeyDecryptor later via a call to boxConfig.setPrivateKeyDecryptor, by the time this becomes possible, BCPrivateKeyDecryptor() has already been instantiated. BCPrivateKeyDecryptor imports BouncyCastleProvider, which we exclude from dependencies to ensure that only FIPS-compliant BouncyCastle libraries are present, resulting in a failure.

Describe the solution you'd like

It would be helpful if the instantiation of JWTEncryptionPreferences became more configurable. For example, moving this instantiation to a default constructor while allowing an alternative constructor, or utilizing interfaces to make it easier to override the functionality altogether.

Describe alternatives you've considered

1. Allowing BouncyCastleProvider in just for the sake of not receiving compilation-time errors.
2. Implementing a fake BouncyCastleProvider to "trick" the compiler.
3. Using reflection.

[jimshowalter]

Instantiation could be at the point of first use, instead of during construction, which would allow clients to specify a different decryptor post-construction.

If the decryptor is still null at the point of first use, assign BCPrivateKeyDecryptor, otherwise leave the override in place.

To avoid compilation problems, the instantiation would need to be done using java.lang.reflect.Constructor, by string name.