Fix double read-lock acquisition in V1

[jasagredo]

Double read lock acquisition

We were running an unsafeAcquireReadAccess inside a withReadLock block. If a write lock arrives exactly in between, the second acquisition cannot continue and neither can the write lock, deadlocking the whole node.

This is solved by acquiring the read lock once, and then "transferring its ownership" onto the forker.

Track the read lock in the resource registry

As we then acquire the read lock, we need to make sure it is cleaned up properly in the presence of exceptions, so we put the allocation in the resource registry. However this means that the registry will try to double free if we actually closed the forker. So we use a TVar that contains a releasing action such that it is the null action if we created the forker.

Track the forker in the resource registry

Now we also need to track the forker once opened in the resource registry, for it to be deallocated if an exception comes. However the deallocation logic of the forker was meant to be run only once, hence it was using takeMVar. We now use tryTakeMVar such that if the forker was properly closed, then the release from the resource registry is void.

[amesgen]

LGTM, thanks!

Maybe we should broaden the scope of #1704 to also (try to) simplify the resource handling of the V1 LedgerDB