Add tracing support parity with log

[ShayBox]

No description provided.

[epage]

This was previously discussed in #37 with #39 being merged.

If we are to discuss this further, I would prefer we do so in an issue before moving to a PR. If nothing else, it keeps the discussion in one place (seeing as we already have 3 PRs related to this topic)

[ShayBox]

Ah I didn't see those issues as they were closed, and It seemed redundant to open an issue to discuss then open a pull request when they're tracked the same as issues.
It also seems redundant to now open an issue to further split the discussion into more pages.

I don't know what the state of tracing / tracing-subscriber was then, but now it appears to be growing in usage and being part of tokio, has good support.
The only reason I see to not merge this is an additional dependency, which can be resolved making log and tracing feature flags, and log enabled by default to keep it from being a breaking change.

[epage]

Please move this conversation to an issue. PRs come and go more often than issues, so they provide a more stable place to hold a conversation. It will also be more discoverable than a rejected PR.

[ShayBox]

You're the only one with the power to move these comments into a separate issue
GitHub Issues and Pull requests are exactly the same, the page url is incremental to both, they're both search indexed on both pages, and they're both as-discoverable as each other, even more so now that they've been referenced from this one.

Anyway, I've said all I needed and submitted my contribution for the discussion, if someone else comes to continue the discussion they can open a new issue
Should this ultimately not be resolved I'll continue to keep my fork synced to upstream, the pull request was more of a last minute action as I didn't search for existing issues, my goal was to create the fork for my own use.