Reenable tracing and change the log level of existing instrument tracing to trace

[bfops]

Problem

We log mostly via the log crate.
We use the tracing and tracing-subscriber crates to configure logging.
For performance reasons, however, tracing is disabled statically for release builds in the public workspace.
As a consequence, any log configuration such as level filters does not apply anymore to log-emitted records -- that is, if one runs an executable with RUST_LOG=trace set, all log records will be output.

This is not great, because it undermines nuanced log configuration within the private workspace.
For example, one might want to temporarily enable debug logging for a particular span (i.e. code path), without opening the floodgates of emitting all debug logs.

Proposed Solution

• Configure tracing in the public workspace to use features = ["release_max_level_info"] by default
• Change all #[instrument] annotations in the public workspace to use level = "trace" by default
  • We may later selectively raise the level of interesting spans created like this
• Revise (default) log configuration for the private workspace (config.toml)
• Confirm that hot-reloading of the log configuration still works (it seems it might not)
• Optional: standardize on tracing instead of log, i.e. replace log::info!, log::debug! etc. with their tracing counterparts. tracing's support for "structured logging" (kv pairs) is invaluable in practice.

[kim]

Some more investigation reveals that setting features = ["release_max_level_*"] in the public workspace will completely prevent tracing from working in the private workspace.

We should set this feature only in the Cargo.toml of binary crates.