A way to disable anyhow stacktraces (without disabling stacktraces from other crates)

[rukai]

Since #333 anyhow errors are now capturing a stacktrace at time of creation and including that stacktrace in cases like format!("{error:?}").
We use anyhow for user facing errors, and make use of anyhow's error chaining to provide a nicely formatted sequence of events that led to the error. The stacktrace adds a huge amount of noise to errors that we would like to avoid.
Additionally we need our error cases to be fast and want to avoid capturing a stacktrace for that reason.

This new functionality can be disabled by RUST_LIB_BACKTRACE=0 which is possibly enough in some cases.
However we also manually reimplement our panic handler to give a custom backtrace, and this would be disabled by RUST_LIB_BACKTRACE=0

[rukai]

I realized that for my use case, I actually use https://crates.io/crates/backtrace instead of std::backtrace.
The backtrace crate doesnt actually check RUST_LIB_BACKTRACE, so I can simply add:

        if std::env::var("RUST_LIB_BACKTRACE").is_err() {
            std::env::set_var("RUST_LIB_BACKTRACE", "0");
        }

To disable anyhows backtraces when RUST_BACKTRACE=1.
This does still allow the user to manually force RUST_LIB_BACKTRACE=1 if they need to.

I'll leave this issue open as it does represent a possible user issue, it is not however an issue that I actually face, so feel free to close this issue.

[dtolnay]

However we also manually reimplement our panic handler to give a custom backtrace, and this would be disabled by RUST_LIB_BACKTRACE=0

I believe the intended way to handle this is that the custom panic handler needs to use Backtrace::force_capture() (https://doc.rust-lang.org/1.75.0/std/backtrace/struct.Backtrace.html#method.force_capture). Then it is no longer sensitive to RUST_BACKTRACE and RUST_LIB_BACKTRACE, so you can use RUST_LIB_BACKTRACE=0 to only control non-panic error handling backtraces.

In the backtrace crate, Backtrace::new() is equivalent to std::backtrace::Backtrace::force_capture() so you effectively arrived at this already as of shotover/shotover-proxy#1408.