Add DefaultSecurityProviderConfig with Bouncy Castle disabled

[exceptionfactory]

This pull request address issue #782 with a new DefaultSecurityProviderConfig that extends DefaultConfig and disables Bouncy Castle Security Provider registration in a static initializer.

As described in the referenced issue, SecurityUtils.isBouncyCastleRegistered() checks current Security Providers and attempts to register Bouncy Castle according to the default settings. The DefaultConfig class checks the status of Bouncy Castle registration to determine whether to configure standard factories, but this introduces unnecessary coupling between Bouncy Castle registration and standard algorithm factories.

Changes in this pull request include removing the SecurityUtils.isBouncyCastleRegistered() check from the DefaultConfig constructor and registering all factories. The initCipherFactories() method already attempts to initialize configured Cipher Factories and disables factories when the corresponding cipher algorithm is not supported. The random factories do not depend on Bouncy Castle registration, and the Key File Provider factories may or may not need Bouncy Castle depending on the particular key protection algorithms. Removing the dependence of Bouncy Castle registration allows the rest of the library to attempt security operations as needed with the potential to support other Security Providers. It is important to note that the DefaultConfig will attempt to register the Bouncy Castle Provider when calling other SecurityUtils methods, but removing the registered check avoids tight coupling to the particular provider.

With the changes to DefaultConfig, the new DefaultSecurityProviderConfig includes a static initializer to call SecurityUtils.setRegisterBouncyCastle(false). This changes subsequent behavior and thus expects java.security settings or other external components to setup the providers necessary. SecurityUtils.setRegisterBouncyCastle() could be called without the introduction of a new configuration class, but new class provides a clear indication of expected behavior, and simple replacement for DefaultConfig when necessary. Additional adjustments include removing SecurityUtils.isBouncyCastleRegistered() from several locations where it should not be required.

[exceptionfactory]

Thanks for rebasing this PR @hierynomus. What do you think about these changes?

As stated in the description, the net effect is removing Bouncy Castle registration has a hard-coded requirement for the standard algorithms and key providers.

At this time, Bouncy Castle is still required for some of the Private Key parsing, and also required for certain algorithms on Java 8, like ChaCha20-Poly1305 and X25519. However, it does move more in the direction of making it optional in some use cases.

[hierynomus]

It's merged :) For now I think this is indeed the best to be done with removing the need for BC.

[exceptionfactory]

Thanks @hierynomus!