Don't trace tasks spawned through the console server

[g2p]

The console subscriber's server generates a lot of async activity,
introspecting or logging that drowns out the activity the program
has outside of instrumentation.

Set a thread-local subscriber that drops events coming from the server thread.

Implementation requires a simple wrapper for NoSubscriber, because the dispatch implementation uses it as a sentinel value (tokio-rs/tracing#2001 explains the history) and logs through the global dispatcher when a thread-local NoSubscriber is set.

[g2p]

(Now that tokio-rs/tracing#2001 is in a release, console could also require that release instead of the NoSubscriber wrapper)

[seanmonstar]

I kinda think the task being shown is useful, since it could help you realize how much the console is affecting your app, or reveal potential bugs in the console server. But I understand wanting to hide it usually. I don't know what the best solution is. Maybe we can dim it, or have a thing at the bottom "2 tasks hidden by default", or some other idea?

[g2p]

I could provide a way to make this configurable, I would put it in console_subscriber::Builder, but the default would be to hide so that a console user gets something relevant with less effort and knowledge. A runtime annotation that could be filtered client-side is also much harder than the thread-local filter in this PR, the annotations don't exist right now.

Aside: Having hyper tasks coming from the subscriber definitely made the console unusable for me at release. Currently tasks like this cannot be distinguished if the app also uses hyper, though better context annotations will hopefully be provided at some point.

Figuring out console bugs or overheads is more relevant to a tokio-console developer, someone also more able to find and configure an "enable_self_trace" flag.

[hawkw]

I agree that it feels a bit philosophically wrong to totally exclude the console's tasks, because then we are not reporting a completely accurate view of the application's real state. But, pragmatically, if the console tasks make using the console more difficult, I'm willing to consider excluding them --- doing so may also improve performance and/or reduce dropped events. So, I agree with @seanmonstar --- we should allow the user to choose whether the console's tasks are recorded or not.

I think in an ideal world, we would want to configure whether or not the console's tasks are recorded in the console UI, using a general-purpose runtime filtering system as described in #131. However, implementing that is a pretty big project --- it would require UI work as well as potential changes to the wire protocol and console-subscriber crates. So, if the console tasks are currently causing problems for users trying to debug their applications, I think a builder option for enabling recording the console's tasks would be a fine stop-gap solution until the more general-purpose filtering system is implemented.

[hawkw]

I think that, rather than always disabling recording on the console-subscriber thread, we should add a builder option to control whether or not it's disabled, and only set NoSubscriber when that builder option is set. I would be fine with making the console-subscriber thread disabled by default, but I think it ought to be possible to enable recording it.

Also, I commented with a couple smaller suggestions, but neither of those are hard blockers for merging this branch.

[g2p]

Addressed comments and made this configurable.

[hawkw]

looks good to me! thank you!

[hawkw]

@g2p mind merging the main branch into this PR so we can get a passing CI build? I'll be happy to merge it afterwards --- it looks like I can't update this branch from main in the GitHub UI, for some reason.

Edit: never mind, I took care of it.

[g2p]

(I just rebased to appease CI. Feel free to merge when that works)