Fix java/unsynchronized-getter CodeQL alerts in DebugLogPublisher

[vharseko]

Closes the two remaining error-severity code scanning alerts, #651 and #652 (java/unsynchronized-getter), on getClassSettings() and getMethodSettings().

#785 already made the trace settings maps concurrent, but the alerts stayed open: the rule is structural — a synchronized setter paired with an unsynchronized getter — and setClassSettings(), setMethodSettings() and removeTraceSettings() still held the monitor.

Rather than locking the getters, this makes the whole access path lock-free:

• Both maps become final, eagerly created ConcurrentHashMaps. They are therefore safely published to every reader without volatile, and the null checks spread over four accessors go away — the constructor always adds the global scope, so null was unreachable anyway.
• synchronized is dropped from all three mutators, so no method of the class is synchronized any more.
• The compound updates keep their atomicity through ConcurrentHashMap.compute() keyed by class name. setMethodSettings() creates the enclosing map and inserts the setting in one atomic step; removeTraceSettings() removes the method and discards the map once it is empty in the same computation. Both go through compute() on the same key, so they remain mutually exclusive.

This matters beyond the alert: getMethodSettings() hands out the live inner map, which DebugTracer caches and reads on the hot traceException() path while an administrative change to a debug target can be mutating it.

Behaviour is unchanged — the walk up the scope hierarchy, the global fallback that only applies while size() == 1, the null returned by getMethodSettings() when no method-level tracing is configured, and the removed settings returned by removeTraceSettings(). The javadoc of getMethodSettings() was also promising an unmodifiable map while returning a live one; it now describes what it returns.

TraceSettings still mutates its own non-volatile fields from applyConfigurationChange() while tracer threads read them. CodeQL does not flag it and it needs a different fix (make the class immutable and replace the instance in the map), so it is left out of this change.

Testing

New DebugLogPublisherTest covers the defaults, the global fallback, the most-specific-scope resolution, the method settings bookkeeping, dropping the enclosing map with its last method setting, and a contention test (4 writers × 2 readers × 5000 rounds) asserting that no setting is lost.

• mvn -pl opendj-server-legacy test-compile — success; DebugLogPublisherTest 6/6 and the neighbouring TraceSettingsTest 3/3 pass.
• Negative control: rebuilding the class with non-atomic mutators (get-then-put, remove-then-cleanup) makes the contention test fail, so it does guard the compute() atomicity rather than passing vacuously.