FileReplicaDB leaks its log reference when its constructor cannot read the CSN limits #819

FileReplicaDB opens its log first and reads its bounds afterwards:

// FileReplicaDB.java:110-120
this.log = createLog(replicationEnv, cryptoSuite);
this.csnLimits = new CSNLimits(readOldestCSN(), readNewestCSN());

DirectoryServer.deregisterMonitorProvider(dbMonitor);
DirectoryServer.registerMonitorProvider(dbMonitor);

readOldestCSN() and readNewestCSN() read the oldest and the newest record of that log and
both declare ChangelogException — a log file which cannot be read is exactly the failure #802
is about. The constructor then fails with the log already opened and already counted:
Log.openLog() either created the cache entry with a reference count of 1, or incremented the
count of an existing one (Log.java:210-228), and only Log.close() releases it — a method
nobody can call any more, because the instance which held the reference was never returned.

So the entry in the static logsCache is pinned for the lifetime of the JVM, together with the
file handles of its log files. In a server, the changelog files of that replica are never closed
and the count never drops to zero. In the test suite, where many replication servers share a JVM
and reuse the same paths, the next server which opens that path gets the stale Log instance out
of the cache — an instance whose files a removeDB() may have deleted in the meantime.

Proposed fix

Release the log when the constructor cannot complete:

this.log = createLog(replicationEnv, cryptoSuite);
try
{
  this.csnLimits = new CSNLimits(readOldestCSN(), readNewestCSN());
}
catch (ChangelogException e)
{
  log.close();
  throw e;
}

This is what shutdown() does with the same log (:216-223). It leaves the closed log in
ReplicationEnvironment.logsReplicaDB, as shutdown() does too: that list is only cleared when
the environment is shut down, and it is read for the CN index logs only
(ReplicationEnvironment.java:496-502).

Found while analysing #813.