ClusteredLockSplitBrainTest fails randomly

When it works
====
node A acquires the lock
Split brain of [A] [B, C, D]

Meanwhile, node B tries to acquire the lock, which is not free, so the request goes to the pending queue of B.

With the view change listener, B calls unlock for A.

The listener of B is notified that the lock is released.

Retries for B

It works, and A can't do anything else because it's not in the majority partition.

When it fails
====
node A acquires the lock
Split brain of [A] [B, C, D]

Meanwhile, node B tries to acquire the lock, which is not free, so the request goes to the pending queue of B.

With the view change listener, B calls unlock for A.

The listener of B is notified that the lock is released.

Retries for B

It fails, because it says that actually the lock is still with locked by A in node D, but it is available in Node B and C.

Another unlock is retried for Node D, and this works, and still tries to unlock B and C, which fail because now thy are locked by B.

This gets on the limbo and the request is expired by the scheduler.