Ensure mempool always closes stale forkers

[jasagredo]

A partial backport of #1714.

The forker was being opened always, and in the following situation it will be leaked and block the V1 LedgerDB lock forever:

• 2 blocks
• which are adopted in (increasing select view order) sequence (possibly by them being part of a slot battle and getting the losing one first)
• very fast so that the mempool tries to revalidate exactly in between the blocks
• it opens and holds forever a forker, it loses all reference to the forker (leaked resource)
• then a flush happens and blocks forever as the (reading) forker in the previous step is open forever, and flushing requests a write lock

[amesgen]

LGTM apart from updating the PR title/commit message to mention that the core improvement here is that we now actually always close the forker. The fact that we don't open them when not necessary is nice/a great way to ensure this, but not the headline.

[jasagredo]

I'm actually going to leave out the change of allocating the thread, because we need resource-registry 0.2 and I don't want to update it here too