Consider making it possible to show trace logs with Firefox release build

[KershawChang]

Why:
We've recently been debugging HTTP/3 issues in Firefox, and the lack of neqo trace/debug logs in release/opt builds makes this much harder

Context:
neqo’s qdebug! / qtrace! cannot be observed in a release/opt Firefox build, even with MOZ_LOG=neqo::*:5. In mozilla-central, the log crate is compiled with release_max_level_info, and neqo’s macros expand to log::trace! / log::debug!, which are gated by the compile-time log::STATIC_MAX_LEVEL. As a result, they are stripped at build time.

[martinthomson]

Good news that I just put up #3763, because the usual reason for not doing this is so that we don't pay a performance tax. At least that cuts 30% off it when enabled.

This will increase binary size quite a bit and add a small amount of performance overhead in release builds. Some amount of that cost will be paid even if the logging is off. I guess you'd want some testing to confirm that the cost is tolerable.

[larseggert]

@mxinden suggested to switch to tracing and make it emit profiler markers.

[mxinden]

In mozilla-central, the log crate is compiled with release_max_level_info

The quick fix would be to change release_max_level_info.

@mxinden suggested to switch to tracing and make it emit profiler markers.

Yes, that would be my long-term preference.

1. I would like to forward tracing crate logs to both the Firefox profiler and Mozilla logger.
   • Tracked in https://bugzilla.mozilla.org/show_bug.cgi?id=1652558.
   • Work-in-progress patch https://phabricator.services.mozilla.com/D309235.
2. I would switch neqo_glue and github.com/mozilla/neqo to use tracing. Standalone (i.e. neqo-client and neqo-server) traces would simply go to stderr. Embedded in Firefox, with (1) above, traces would be forwarded to the Firefox profiler and the Mozilla logger.
   • Tracked in https://bugzilla.mozilla.org/show_bug.cgi?id=2005955.
   • Work-in-progress patch https://phabricator.services.mozilla.com/D309236.