First class notion of runtimes

[hawkw]

A Tokio application is capable of having multiple independent runtimes. I believe this may be the case for other runtime implementations as well (e.g., I believe rayon allows creating multiple separate threadpools). This may also be useful when a crate uses multiple async runtimes provided by different libraries (e.g. running async-stds global runtime in a bg thread).

Currently, the console has no way of being aware of this --- we just see a lot of tasks, without any way of determining which runtime a task is running on. It would be nice to be able to tag tasks with runtimes. In the future, when we add runtime-global stats/metrics, we will also want a way to uniquely identify runtimes.

As a first pass, we could consider adding a field to the task spans in Tokio with some kind of runtime ID (could just increment an integer every time Runtime::new is called), and add that to the task spans when spawning. This would at least let users distinguish between runtimes by looking at the task's fields. Tokio could also add a new (unstable) builder method to allow naming the runtime itself, as well as naming its worker threads.

Building on that, we could make the console subscriber actually aware of this field, and allow associating tasks with runtimes. We could consider adding a new RPC to list runtimes and/or get per-runtime stats.

[jplatte]

Somewhat related, the task_group crate provides another way of grouping tasks and it would be awesome if that could be visualized as well. (just something that came to mind when reading this issue, I haven't actually attempted to use Console with a project that uses that crate)

[hawkw]

This is also going to be necessary in order to integrate with Tokio's runtime metrics API (tokio-rs/tokio#4073), cc @LucioFranco.

[hawkw]

I imagine the wire format changes are going to be something like this:

• add a "runtime ID" to identify runtimes
• add a "watch runtimes" RPC that returns a stream of runtime stats updates, and a map of any newly-detected runtimes (similarly to how the tasks RPC works)
• add (optional) runtime ID fields to tasks, identifying which runtime the task is running on.