With tree-states hot and our improved pruning algorithm, I'm 99% sure we don't need the artificial transaction_mutex inside the hot/freezer DB.

The reason it was originally introduced was to prevent inconsistencies caused by the same state being written-from/deleted-from multiple threads concurrently. With pruning now revised to delete any stray states based on a walk of the hot state summaries, we no longer need to worry. E.g. the following scenarios are all fine:

• If we write the same state from two different threads, it should be identical. In the worst case we repeat a bit of IO getting it on disk.
• If we write a state that has been deleted by pruning, it will be pruned again the next time pruning runs (in this case the block should usually fail to be imported, but even if it is imported, we will prune this state).

If we can't come up with a counterexample that demonstrates the necessity of the lock, we can delete it as part of the tree-states hot PR, or shortly after:

• Hierarchical state diffs in hot DB #6750