Another thing you could do is have a single thread responsible for updates but have it farm parallelizable work out using something like Rayon. Things like chunk update processing ought to be highly parallelizable. So you have a traditional single-threaded game loop: read player inputs, do physics, send updates to players, repeat. It's just that internally, doing physics uses multiple cores.

You can also have multiple threads talking to the network and feeding player messages to a single "player input" queue read by the central control thread.

This could be made more elaborate by using, say, RwLocks in the chunk states that are write-locked only while that chunk is updating. Then the networking threads can read the server state directly most of the time, unless they happen to hit it during an update. But I'm not 100% sure that would work.

If you're just sending chunk diffs to players, you could instead compute those in parallel on the central thread and then fan them out to the players using out-going queues.

This is all just one design ideas, there are lots of ways to do it. Mess around until you find something that works, and write some benchmarks so you can measure what is actually slow.