Deadlock when concurrent node modification in berkeley

Nobody has claimed this yet.

Example of code

```
@Test
void deadlock(@TempDir File file) throws InterruptedException {
JanusGraph graph = JanusGraphFactory.open("berkeleyje:" + file.getAbsolutePath());

graph.traversal().addV().property("a", "b").iterate();
graph.tx().commit();

for (int i = 0; i < 2; i++) {
new Thread(() -> {
try (Transaction tx = graph.traversal().tx()) {
graph.traversal().V().has("a", "b").property("a", Thread.currentThread().getName()).iterate();
tx.commit();
}
}).start();
}

Thread.sleep(6000);
System.out.println(graph.traversal().V().valueMap().toList());
}
```

Exception
```
Caused by: com.sleepycat.je.DeadlockException: (JE 7.4.5) Deadlock was detected. Locker: "1158783940 42_Thread-10_Txn" was chosen randomly as the victim.
DB: edgestore. Timeout: 500ms.
Locker: "1158783940 42_Thread-10_Txn" waits for lock: 582057117(LSN: 0x0/0x1227, requestType: WRITE).
Locker: "2098131681 43_Thread-11_Txn" owns lock: 582057117(LSN: 0x0/0x1227, ownedType: READ). Locker: "2098131681 43_Thread-11_Txn" waits for lock: 582057117(LSN: 0x0/0x1227, requestType: WRITE).

at com.sleepycat.je.txn.LockManager.makeDeadlockException(LockManager.java:1083) ~[je-7.4.5.jar:7.4.5]
at com.sleepycat.je.txn.LockManager.checkAndHandleDeadlock(LockManager.java:924) ~[je-7.4.5.jar:7.4.5]
at com.sleepycat.je.txn.LockManager.waitForLock(LockManager.java:475) ~[je-7.4.5.jar:7.4.5]
at com.sleepycat.je.txn.LockManager.lock(LockManager.java:345) ~[je-7.4.5.jar:7.4.5]
at com.sleepycat.je.txn.Txn.lockInternal(Txn.java:539) ~[je-7.4.5.jar:7.4.5]
at com.sleepycat.je.txn.Locker.lock(Locker.java:499) ~[je-7.4.5.jar:7.4.5]
at com.sleepycat.je.dbi.CursorImpl.lockLN(CursorImpl.java:3641) ~[je-7.4.5.jar:7.4.5]
at com.sleepycat.je.dbi.CursorImpl.insertRecordInternal(CursorImpl.java:1385) ~[je-7.4.5.jar:7.4.5]
```
For fix it, change default isolation level (LOCK_MODE) to LockMode.READ_UNCOMMITTED

But if we want to use default lock mode, we can increase EnvironmentConfig.LOCK_TIMEOUT (default 500ms), so another way to fix that make it parametr customizable

Start by running the supplied JUnit reproduction against the Berkeley backend and inspect how LOCK_MODE and EnvironmentConfig.LOCK_TIMEOUT are exposed. Done means the selected fix is covered by a regression test and the required Berkeley lock behavior or timeout is configurable.

Written by the indexing model from the issue text.