OPENDJ-1116 Introduce abstraction for the changelog DB


Slayered walking dead code.
Walking dead code is code that looks it is alive, tastes just like if it was alive, but there is funny smell about it, and actually... it turns out this code is dead.
ReplicationServerDomain.getEligibleState() is walking dead code because:
- JEChangelogDB.getCSNAfter() always returns null: the API of ReplicaDBCursor mandates to call call next() before calling getChange(), however getCSNAfter() fails to do so, hence getChange() always returns null, which means getCSNAfter() always returns null.
- the "result" local variable is a duplicate of "latestState", which means it starts of with the exact same state. The code iterates through "latestState" to get its CSNs, calling update() on "result" with these CSNs. But... since "result" duplicates "latestState", it has the exact same CSNs, which means calling update() will have no effect on "result", leaving it on the same state as it was before the iterations.


ECLServerHandler.java, ReplicationServer.java:
Replaced ReplicationServerDomain.getEligibleState() with ReplicationServerDomain.getLatestServerState().duplicate() where applicable.

ReplicationServerDomain.java:
Removed getEligibleState() which does literally nothing, but in a very inneficient way.

ReplicationDomainDB.java, JEChangelogDB.java:
Removed getCSNAfter(), now become unused.