Remove per-attribute read lock from CompressedSchema decode path

[vharseko]

Summary

Another BIND/read hot-path serialization point found while profiling after
#660: CompressedSchema.decodeAttribute() / decodeObjectClasses() acquire
a ReentrantReadWriteLock read lock for every attribute of every entry
read from a backend. Decoding one user entry takes K+1 lock acquisitions
(~20+ per bind), i.e. hundreds of thousands of CAS operations per second on
one contended cache line under load. This PR makes the read path lock-free.

Problem

Every decode calls reloadMappingsIfSchemaChanged(), which took the shared
lock just to compare the schema reference and read the mappings reference:

sharedLock.lock();          // K+1 times per entry decode
try {
  if (schema != serverContext.getSchema()) { ... }
  return mappings;
} finally { sharedLock.unlock(); }

Read locks do not block each other, but every acquire/release is a CAS on
the RRWL sync word — a cross-core cache-coherency hotspot on the per-backend
singleton (PersistentCompressedSchema). The Mappings internals are
already concurrent collections (CopyOnWriteArrayList for the id→element
decode maps, ConcurrentHashMap for the encode maps), so the lock only
guarded reads of two references.

Change

• schema and mappings become volatile and are read lock-free on the
  decode path. On schema reload the new mappings reference is published
  before the schema reference, so a reader that observes the current
  schema is guaranteed to observe the mappings rebuilt for it (ids are
  stable across rebuilds).
• getAttributeId() / getObjectClassId() (encode path) get the same
  lock-free fast path via the encode ConcurrentHashMap; registration of a
  new id stays serialized on the exclusive lock, re-reading the mappings
  reference under the lock since a concurrent reload may have replaced it.
• The ReentrantReadWriteLock is replaced by a single ReentrantLock used
  only by mutators (id registration, schema reload). Behaviour is otherwise
  unchanged.

Benchmark

Same harness as #660/#667/#669: packaged server, je backend, 5,000 users
({SSHA}), authrate with 200 persistent connections re-binding as random
users, JDK 11, 8-core host. Interleaved A/B (old → new → old → new after a
cool-down, warm-up run before each measurement) to control for thermal
drift:

round	old (RRWL per attribute)	lock-free (this PR)
1	27,922 ops/s / 7.22 ms	34,008 ops/s / 5.91 ms (+22%)
2	30,994 ops/s / 6.61 ms	31,385 ops/s / 6.42 ms (+1.3%)

Both rounds favor the lock-free version (avg +11% throughput, lower
latency); variance on the shared 8-core host is high, and as with #667/#669
the structural win is removing a serialization ceiling that grows with core
count. authrate errors: 0.

Review follow-up (7a290de)

reloadMappingsIfSchemaChanged() now captures the mappings reference
once under the exclusive lock (final Mappings oldMappings = mappings;)
and reuses the local for the size calculation and both reload calls.
Not required for correctness — all mutations are serialized by the same
lock, so the repeated volatile reads saw one value — but it makes the
reload-from-one-snapshot intent explicit and matches the pattern already
used in getAttributeId()/getObjectClassId().

Testing

mvn -P precommit -pl opendj-server-legacy verify for
ModifyOperationTestCase (932), AddOperationTestCase (137),
TestDnKeyFormat (30) — entry encode/decode and schema paths:
1099 tests, 0 failures — re-run with the same result after the
review follow-up.

Files

• opendj-server-legacy/src/main/java/org/opends/server/api/CompressedSchema.java