Name or classify tasks spawned by the subscriber runtime

[seanmonstar]

The subscriber starts its own runtime and server, and those tasks are instrumented and shown in the Console too. That is actually useful in some situations. But it also can be distracting. It would help if we could name or classify any tasks in that runtime to help a user viewing the Console, so they understand "oh, those aren't my tasks".

[hawkw]

Since using the console already requires enabling tokio_unstable, we can probably just use task::Builder to add a name, anywhere we spawn a task.

In the future, it would be nice to be able to associate tasks with runtimes, and name runtimes as well. That way, we could say things like "hide all tasks belonging to the console runtime". But that would require new instrumentation in Tokio, so it's a bigger project.

[hawkw]

#117 added names to the console's aggregate and serve tasks. However, we can't easily name the per-connection tasks spawned by Tonic without switching to tonic's lower-level API and writing our own accept loop to spawn those tasks on our own. We'll do that in a subsequent branch (or consider changes upstream?)

[g2p]

Could the many tonic / hyper tasks be filtered out using spans and layers?
I don't know enough about tracing to know if logic like metadata.is_within_span is implementable.
Edit: something like a dynamic_filter_fn?
When debugging a hyper-based application tonic adds a lot of noise, ways to hide or at least distinguish would be welcome.

[hawkw]

@g2p it's definitely possible to use dynamic_filter_fn to filter out those spans at the subscriber-level, but I think the best long-term solution is to add filtering to the console UI: #131