The Inventory mutex is too omnipresent

[IntegratedQuantum]

In #1739 I noticed that every block updates needs to lock the inventory mutex, since it needs to be locked when breaking a chest to remove the inventory.

Generally it would be nicer if this was less coupled, particularly it is problematic that we even get into the situation that the inventory mutex leaks into the update block function, this has a big risk of causing severe deadlocks in the future.
I'm not sure how this could be prevented though, since otherwise there is a risk that the inventory gets changed while breaking/placing a block (e.g. maybe the player collects something) which in turn changes the eligibility of breaking a block.

I think the right solution may be to avoid having a global mutex at all, maybe a per inventory mutex suffices? This does however make it more likely to deadlock for operations on multiple inventories.

[IntegratedQuantum]

I think the best solution for this would be to execute all the inventory (and other sync-related) code on the server in a single thread, the update thread, asserting that we are on the right thread, instead of locking a mutex.

If you think about it, all this locking is problematic since we end up basically in a single threaded situation anyways, so why not move it all into one thread. If in the future we do need multiple threads, then a dynamic work scheduling system, that considers which tasks execute on the same resources, could be implemented instead, but let's keep it simple for today. I think most gains will come from parallelizing expensive operations like pathfinding and AI anyways.

[IntegratedQuantum]

Alright I think I know what we can do, if we ever have a need to parallelize this.

I made the following observations:

1. inventory operations can be executed out of order, if they don't move stuff around (e.g. taking durability, removing items, adding health), as long as we don't care about which operations fail in case of resource shortage.
   e.g. imagine mining 2 blocks behind each other, but (through some other event that the client couldn't know about) the pickaxe only has 1 durability left. This restriction would mean that the game is allowed to break only the further away block.
   I think this is acceptable, given that any player-action cancellation is going to be confusing to the player and generally this would require quite specific circumstances.
2. Most player actions happen on a large time-scale. A non-cheating player will not insta-switch while mining blocks at sub-tick speeds.
3. When block updates only ever read there direct neighbor (and never write), then we can parallelize block updates on a checkerboard pattern, first updating all chunks with even (x + y + z), then updating all chunks with odd (x + y + z).
4. Writing could be achieved through events executed in future frames

So overall, we can run inventory operations in parallel, as long as we separate moving operations from non-moving operations, and execute moving operations sequentially.

For now though, the first step in either case is to push things onto the update thread. It's nice to see that parallelization is possible in principle, though I still doubt we need to even go that far.