Keep PKCS5S2 usable on a FIPS-restricted JCE, and name the key wrapping property when the runtime has no RSA-OAEP

[vharseko]

Problem

#1054 changes the config template to get a server installed on a FIPS 140-3 Java runtime: it disables the PKCS5S2 password storage scheme and sets key-wrapping-transformation to RSA/ECB/PKCS1Padding. The review there explains why neither belongs in the template — PKCS5S2 is PBKDF2-HMAC-SHA1 like the PBKDF2 scheme which stays enabled, and PKCS#1 v1.5 is the transformation #776 removed as a CodeQL java/rsa-without-oaep finding. What actually fails on such a runtime:

• PKCS5S2PasswordStorageScheme asked for SecureRandom "SHA1PRNG" by name, at initialization and in the offline encoder. A FIPS-restricted JCE registers no such algorithm, the scheme threw a message-less InitializationException, and the server refused to start.
• The crypto manager validates its key wrapping transformation when it is created. A runtime whose only RSA cipher is PKCS#1 v1.5 — a SunPKCS11 provider on its own, as on a Linux system in FIPS mode; JDK-6190389 is still open — cannot start the server with the RSA-OAEP default. Setup noticed (ConfigureDS.updateCryptoCipher), had no secure fallback left after Fix java/rsa-without-oaep CodeQL alert by dropping the RSA PKCS#1 v1.5 fallback #776, and silently kept the default; the failed start which followed named the cipher it could not get and nothing else.

Change

• PKCS5S2PasswordStorageScheme takes the provider's default SecureRandom, as the PBKDF2 family does, and its InitializationException — like the PBKDF2 schemes' — names the algorithm which is missing. The SHA1PRNG constant goes. The template keeps the scheme enabled.
• setup prints a warning naming the transformation, the reason and the property to set before the first start (WARN_CONFIGDS_KEY_WRAPPING_TRANSFORMATION_UNSUPPORTED), and the crypto manager's refusal (ERR_CRYPTOMGR_CANNOT_GET_PREFERRED_KEY_WRAPPING_CIPHER) names the property too. The choice itself stays with the administrator: the install guide gains "To Install OpenDJ Directory Server on a FIPS 140 Java Runtime" — with the bundled BC-FIPS provider, which offers RSA-OAEP, the default configuration works as it is; a SunPKCS11-only runtime gets the setup --doNotStart → ldifmodify → start-ds procedure, with the caveat that PKCS#1 v1.5 is disallowed for key transport by NIST SP 800-131A Rev. 2 and that every replica must use the same transformation.
• A FIPS-approved key transport for such runtimes (SP 800-56B KTS-KEM-KWS over RSA/ECB/NoPadding) is Crypto manager: a FIPS-approved key transport for JVMs whose only RSA cipher is PKCS#1 v1.5 (SunPKCS11) #1056.

Testing

The new tests withdraw the JCE providers which register a service, run the code without them, and put the providers back where they were (TestCaseUtils.withoutJceService):

• PKCS5S2PasswordStorageSchemeTestCase: the scheme initializes and encodes, online and offline, without SHA1PRNG (SUN withdrawn, BC-FIPS standing in for the digests); its initialization failure names PBKDF2WithHmacSHA1 (SunJCE withdrawn). The same failure test for PBKDF2PasswordStorageSchemeTestCase.
• ConfigureDSTestCase (new): the default transformation stays where the runtime has it; without Cipher.RSA none is chosen and the exception names the default.
• CryptoManagerTestCase: an unsupported transformation is refused, and the refusal names key-wrapping-transformation.

Each test was run red before its fix and green after: PKCS5S2PasswordStorageSchemeTestCase 56/56, PBKDF2PasswordStorageSchemeTestCase 40/40, PBKDF2HmacSHA256/512PasswordStorageSchemeTestCase 39/39 each, CryptoManagerTestCase 31/31, ConfigureDSTestCase 2/2.

Alternative to #1054. Related: #776, #1056.