Worker State should be exclusively modified through batched comms

This is a high level epic.

The Worker State Machine (`distributed/worker_state_machine.py`) can be exclusively updated through the `Worker.handle_stimulus` handler. _Most_ calls that change the worker state coming from the scheduler are dealt through batched comms, which has the notable feature of being strictly sequential. This makes it a lot harder to introduce subtle race conditions where the worker state is not where the scheduler thinks it it.

There are three notable offenders that bypass the batched comms and use RPC instead:

- rebalance (to be migrated to use batched comms in #4906)
- replicate (to be migrated to use batched comms in #6578)
- scatter (TODO sub-issue to address it)

If you use any of these calls, you may have
1. a rebalance/replicate/scatter command is fired through RPC by the scheduler
2. another command is fired by the scheduler through batched send, e.g. `free-keys`
3. the two commands land on the worker in the opposite order as they were sent by the scheduler

e.g. the scheduler may send free-keys as it wants the worker to forget the key, and then shortly afterwards it may scatter data with the same key to the worker; but the worker will instead receive the scattered data first, which will transition the key to memory, and then free-keys, which will make it lose the scattered data.

CC @fjetter @gjoseph92