Remove global digestLock serialization in digest password storage schemes

[vharseko]

Summary

Removes another global serialization point on the BIND hot path, found while
profiling after #660: every digest-based password storage scheme shares a
single MessageDigest instance guarded by synchronized (digestLock).
Schemes are server-wide singletons, so all concurrent bind password
verifications for a given scheme (e.g. every {SSHA} bind) serialize on one
monitor — with the CPU-bound hashing executed under the lock. The same
pattern is removed from the CRAM-MD5 SASL handler and from the UNIX
crypt(3) implementation behind the {CRYPT} scheme.

Problem

SaltedSHA1PasswordStorageScheme.passwordMatches() (and its siblings) hash
the candidate password inside a global synchronized block:

synchronized (digestLock)
{
  userDigestBytes = messageDigest.digest(plainPlusSalt);
  ...
}

Under concurrent BIND load (packaged server, je backend, 5000 users with
{SSHA} passwords, 200 client connections re-binding as random users via
authrate), JFR jdk.JavaMonitorEnter shows this is the dominant monitor
contention once the access-log queues are out of the way: 949 blocking
events totalling ~19 s per 80 s recording across 16 worker threads, with
individual waits of 10–18 ms. After this change the monitor disappears from
the profile entirely.

Change

• Digest schemes + CRAM-MD5 (Salted{SHA1,SHA256,SHA384,SHA512,MD5},
  SHA1, MD5, CRAMMD5SASLMechanismHandler): replace the shared
  MessageDigest + digestLock with a ThreadLocal<MessageDigest>
  (ThreadLocal.withInitial); the synchronized wrappers are removed,
  bodies are otherwise unchanged (including the Arrays.fill password
  scrubbing in finally). initialize* still performs a fail-fast
  MessageDigest.getInstance() so an unavailable algorithm keeps throwing
  InitializationException at startup, as before.
• util/Crypt.java (UNIX crypt(3)/DES used by the {CRYPT} scheme's
  unix mode): the shared SubCrypt working-buffer state guarded by the same
  lock becomes a ThreadLocal<SubCrypt>. This also fixes a pre-existing
  race: _crypt() returns a reference to the shared _iobuf buffer, and
  crypt() converted it to bytes after releasing the lock, so a
  concurrent call could overwrite the result while it was being read.

Testing

• mvn -P precommit -pl opendj-server-legacy verify for all affected
  scheme test cases + CRAMMD5SASLMechanismHandlerTestCase +
  CryptPasswordStorageSchemeTestCase: 357 tests, 0 failures.
• Concurrent bind benchmark (same harness as Remove per-bind global lock contention in AuthenticatedUsers #660) confirms the digestLock
  monitor is gone from JFR/jstack profiles; on an 8-core machine the
  operating point is CPU-saturated so throughput is unchanged (+~1%), the
  win is removal of the serialization ceiling on wider machines.

Files

• opendj-server-legacy/src/main/java/org/opends/server/extensions/Salted{SHA1,SHA256,SHA384,SHA512,MD5}PasswordStorageScheme.java
• opendj-server-legacy/src/main/java/org/opends/server/extensions/{SHA1,MD5}PasswordStorageScheme.java
• opendj-server-legacy/src/main/java/org/opends/server/extensions/CRAMMD5SASLMechanismHandler.java
• opendj-server-legacy/src/main/java/org/opends/server/util/Crypt.java