Fixed an issue where deadlocks could occur in the LockManager when the server is in heavy add/mod load. An add operation takes a read lock on the parent DN and a write lock on the target DN in that order. However, mod operations first takes an write lock on the target DN then inadvertantly tries takes an read lock on the parent DN through the entryExists method. This could cause a deadlock in the following case with the fair ordering reentrant read write lock:

Thread 1 is performing a modify operation on cn=dep2,cn=dep1,dc=example,dc=com (entry 2)
Thread 2 is performing an add operation on cn=dep2,cn=dep1,dc=example,dc=com
Thread 3 is performing an modify operation on cn=dep1,dc=example,dc=com (entry 1)

Thread 1 takes a write lock on target entry 2
Thread 2 takes a read lock on parent entry 1
Thread 3 tries to acquire write lock on target entry 1
Thread 2 blocks trying to acquire write lock on target entry 2
Thread 1 blocks trying to acquire read lock on parent entry 1

Threads 1, 2, and 3 deadlocks since thread 3's write lock request is before thread 1's read request in the wait queue.

The entryExists method in Backend.java does not need to acquire an read lock on the DN before checking for the entry's existance in the DB, much like the getEntry method. Removing the lock acquisition in entryExists ensures all locks are acquired down the DIT.

The DependencyTest unit-test now passes and is enabled.

Fix for issue 2852