fmt: Support reloading enabled levels during runtime about tracing HOT 1 CLOSED

👍, this would be nice to have.

Here's how I'd probably do it:

1. We could add a new function to FmtSubscriber that takes a new filter and changes the filter to the previous value.

2. Then, we could use the subscriber downcasting API that was added in tokio-rs/tokio#974 to invoke that function on the FmtSubscriber. So, when we set the subscriber as the default, we could hold onto a Dispatch pointing to it, and use that to call the function that changes the filter, like this:

   dispatch.downcast_ref::<FmtSubscriber<...>>()
       .expect("Dispatch should still point to FmtSubscriber")
       .set_filter(new_filter);

   We could also provide a free function or something that gets the current default Dispatch, tries to downcast it to a FmtSubscriber, and calls the set_filter function if it is one.

3. For now, any subscriber which wishes to dynamically change its filter at runtime will need to return Interest::sometimes for all calls to register_callsite, so we would need some way of indicating whether or not this will occur when building the FmtSubscriber. I have some thoughts on how to do that in a type safe way that guarantees the filter won't be modified unless we state that it can.

4. Furthermore, we might want to consider adding an API to tokio-trace-core to allow completely invalidating and rebuilding all the cached Interests. This would allow the subscriber to return Interest::always and Interest::never, and invalidate the cached values only if the filter changes. This is almost certainly better for performance than re-evaluating the filters every time (although actually changing the filters would be a relatively slow operation). Adding a function like that to -core is tracked by tokio-rs/tokio#1038.

from tracing.