Profiling data of Scheduler.update_graph for very large graph

I recently had the pleasure to see how the scheduler reacts to a very large graph. Not too well.

I submitted a graph with a couple million tasks. Locally it looks like 2.5MM tasks but the scheduler later says less. Anyhow, it's seven digits. update_graph ran for about 5min, i.e. also blocking the event loop for that time (https://github.com/dask/distributed/issues/7980)

What is eating up the most time is

| Function | value |
|------------------------------------------------------------|-------|
| particularly [this](https://github.com/fjetter/distributed/blob/7fc6900d9d23df39234031d64e713b03c240df2a/distributed/protocol/pickle.py#L70) check for `__main__` in dumps result | 5% |
| stringfiy | 12% |
| key_split | 12% |
| unpack_remotedata | 12% |
| generate_taskstate | 20% |
| dask.order | 12% |
| transitioning all tasks | 10% |
| Other foo (e.g. walking the graph for deps and such) | 17% |

It also looks like the TaskState and all the foo attached to them is taking up about 65% of the memory which in this case is about 82GiB. Assuming we're at 2MM tasks that's roundabout 40KB per TaskState. That's quite a lot.

[scheduler-profile.zip](https://github.com/dask/distributed/files/12030389/scheduler-profile.zip)

Nothing to do here, this is purely informational.