[#816] Unmap only the locked domainMap in FileChangelogDB.removeDomain()

[vharseko]

Fixes #816.

FileChangelogDB.removeDomain() reassigned the local variable whose monitor it was holding: a racing shutdownDB() drain, clearDB() or a concurrent removeDomain() made domainToReplicaDBs.remove(baseDN) return null, and the next line threw NullPointerException instead of the ChangelogException callers such as ReplicationServerDomain.clearDbs() handle.

The entry is now removed only while it still maps the instance the monitor was taken on (an identity check under that monitor, which is what makes the check-then-remove atomic: every remover takes the same monitor before unmapping), and iteration stays on that instance:

• replica DBs a concurrent remover already visited are cleared and shut down again harmlessly — Log.clear() returns at once on a closed log and FileReplicaDB.shutdown() is CAS-guarded;
• a domainMap concurrently recreated for the same baseDN by getOrCreateReplicaDB() is left untouched instead of being unmapped while holding the wrong monitor.

The new FileChangelogDBTest reproduces both windows deterministically: it holds the domainMap monitor, waits via ThreadMXBean until removeDomain() blocks on exactly that monitor, and simulates the concurrent remover inside the window. Both tests fail on the unfixed code — removeDomainRacingConcurrentRemovalMustNotThrowNPE with the exact NPE from the issue — and pass with the fix.