subscriber: add more ergonomic subscriber configuration APIs

[hawkw]

Motivation

Users have said fairly frequently that configuring new subscribers in an
application is unnecessarily verbose and confusing. We should try to
make this nicer, especially as it's a common "on ramp" for new tracing
users.

Solution

This branch adds new APIs, inspired by tonic and warp, that should
make setting up a subscriber a little less verbose. This includes:

• Many modules in tracing-subscriber now expose free functions
  that construct default instances of various types. This makes
  configuring subscribers using these types more concise, a la warp.
• An extension trait for adding .set_default, .init, and .try_init
  methods to subscribers. This generalizes the similar functions on
  fmt's SubscriberBuilder to work with other subscribers.

All the old APIs are still left as they were previously. The new APIs
just provide shorthand for them.

[yaahc]

We could have set_global_default and init?

color_backtrace uses install() which I quite like. As for the try_init vs init. I'm kinda of the opinion that the panicking version might just be the better version to push people towards, because how often are you going to want to recover from errors configuring the global logger?

I think it might be okay to only have init and direct people to use the less ergonomic but existing tracing::subscriber::set_global_default if they want to recover from from the failure. My guess is that most people will be fine with using init, and if people are really annoyed by the inconsistent ergonomics between panicking and non-panicking global setup we can always add try_init or set_global_default to the trait later.

[yaahc]

I wish there was a way to replace this expr with something like tracing_subscriber::fmt(), aka some sort of conversion fn for a fmt builder to a registry + layer

[davidbarsky]

I think this is a pretty good improvement and I'm not seeing any issues. I'd like to try this out and report back if I run into any issues.

[hawkw]

@yaahc are you good with this or do we want to continue bikeshedding naming? I'm open to further discussion if you don't like the current scheme.

Re:

I think it might be okay to only have init and direct people to use the less ergonomic but existing tracing::subscriber::set_global_default if they want to recover from from the failure. My guess is that most people will be fine with using init, and if people are really annoyed by the inconsistent ergonomics between panicking and non-panicking global setup we can always add try_init or set_global_default to the trait later.

Hmm, maybe...I think the main use-case for the non-panicking version of the API, besides cases where people want to return as many errors from main as possible, rather than panicking, is one where we don't know if a global subscriber has been set or not. For example, this is pretty common in tests, where people want to say things like

#[test]
fn my_great_test() {
    // ignore errors if another test has already set the global subscriber
    let _ = tracing_subscriber::fmt()
        .with_whatever(...)
        .try_init();

    // ...
}

which is also a pretty common pattern in the env_logger world.

And, since trying to set a global subscriber in tests is one of the few cases where people will actually initialize a subscriber more than once per program, I think it may actually be one of the cases where providing an ergonomic API has the most impact...

What do you all think?

[yaahc]

This makes sense and i agree with it. +1