Migrate to fastrace/logforth

[nikki-aranya]

We currently use tracing/tracing-subscriber and not only are they extremely heavy, but we don't even use most of the features they provide.

tracing-subscriber's env-filter feature alone adds over 300KB of binary size to aranya-daemon, and tracing overall adds a full 1MB to our end binary size (I've been able to reduce aranya-daemon from 3MB to ~2.1MB by removing it). Additionally, tracing doesn't seem particularly interested in the binary size issue, given tokio-rs/tracing#1425 has been open for over 3 years, as well as tracing-core 0.1.31 increasing binary size significantly, which is the reason that rust itself hasn't updated the dependency in 8 months: rust-lang/rust#127316 (comment).

We would be much better served by using logforth which does still provide an env-filter for us to define the log level at runtime, and fastrace still allows our extremely basic #[instrument(skip_all)] span support, support for attaching properties like we use for some function fields, as well as optimizing out completely when not compiled with the enabled feature.

On top of this migration, going along with all the docs work, we should also be putting a lot more thought into what we actually log and what is "useful" information for users to have, but theoretically this migration should be pretty straightforward.

[jdygert-spok]

If we switch to something without tracing compat, then we won't be able to see logging of many of our dependencies.

AFAICT the majority of the size is from tracing_subscriber, not tracing itself. It seems like we'd be better off just replacing tracing_subscriber, either entirely or when needed per project or by flags.

[nikki-aranya]

We can figure out what downstream dependencies we actually want tracing logs for (should probably be a compile flag) but implementing a tracing::Subscriber translation layer for logforth and then switching to fastrace for our own instrumentation is entirely possible. This move is motivated by how slow tracing is just as much as the binary size concerns.

[jdygert-spok]

I see fastrace has impressive microbenchmarks for entering spans, but I'm doubtful of the actual impact it will have when entering a span already takes only a few microseconds.