Add tracing support

[jaybosamiya-ms]

Resolves #171.

This PR enables tracing for LiteBox, and set up a subscriber for the Linux userland. Specifically, this adds LITEBOX_LOG environment variable to the litebox_runner_linux_userland, which can be used like the following:

• LITEBOX_LOG=debug: Show debug and higher-level logs for all crates and modules
• LITEBOX_LOG=litebox::fs=debug: Specifically litebox::fs code at debug and higher-level
• LITEBOX_LOG=litebox=debug,litebox::fs=trace: Multiple filters at different levels

This was previously not quite possible because we could not have real Rust thread locals (which tracing uses internally), but now that that works, we can enable tracing.

Currently, I have not added much in the form of tracing logs/messages much in the code and just added it for LiteBox object initialization. Future PRs will enable it in more places so that we can more easily see a whole bunch more of what is happening easily.

Here's a test output:

$ LITEBOX_LOG=litebox=trace cargo run --bin litebox_runner_linux_userland -- --unstable --interception-backend rewriter target/dev_bench/hello_static_rewritten
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.13s
warning: the following packages contain code that will be rejected by a future version of Rust: num-bigint-dig v0.8.4
note: to see what the problems were, use the option `--future-incompat-report`, or run `cargo report future-incompatibilities --id 1`
     Running `target/debug/litebox_runner_linux_userland --unstable --interception-backend rewriter target/dev_bench/hello_static_rewritten`
   0.001065242s DEBUG litebox::litebox: LiteBox instance initialized
argv[0] = target/dev_bench/hello_static_rewritten
envp[0] = LD_AUDIT=/lib/litebox_rtld_audit.so
Elapsed time: 0.088816 seconds

[github-actions]

🤖 SemverChecks 🤖 No breaking API changes detected

Note: this does not mean API is unchanged, or even that there are no breaking changes; simply, none of the detections triggered.

[jstarks]

I have some concerns with tracing for a project at this level of the stack--in particular, the generated code for a trace point is quite large, and performance of the subscriber model is fundamentally bad. I have made some improvements in the latest release (see tokio-rs/tracing#3398), but I am not optimistic about further improvements without making breaking changes. And the tracing maintainers are severely overworked, so I don't think we can count on that even if we do the work.

So, I think for embedded-ish kernel projects, we'll likely need to turn tracing off completely at compile time to avoid code bloat, defeating the purpose of the traces. I wonder if it might be better to look at log or defmt or even our own set of litebox logging macros to avoid this limitation.

An advantage of litebox-specific logging macros is that we could back them with different implementations depending on compile-time configuration. So, we could back them by tracing for the userland platforms for ease of use where binary size doesn't matter so much, but use defmt or something similar for kernel platforms.

What do you think?

[jstarks]

(Note that litebox-specific code becomes more complicated if you want to support spans and not just events. But in the context of LiteBox, I am skeptical that spans have value commensurate with their runtime cost.)

[jaybosamiya-ms]

Briefly summarizing a longer discussion on Teams b/w @jstarks and myself: we are now considering a facade over log rather than depend on tracing directly in our library crates.