Better error reporting for internal errors

[mikrostew]

Issue

There are currently a number of Notion internal errors in the code:

$ grep -nIr "\.unknown()" crates/ src/ | wc -l
      82

Normally users should not run into these, but when they do there is not much info provided about what happened so that we can reproduce the error.

Proposal

For internal errors, I propose that we:

1. Log the error details to a file (backtrace, environment, whatever we can get)
2. Include the location of that file in the error message describing how to report the error, so that the use can include it

[dherman]

Some thoughts about RUST_BACKTRACE: I feel like we shouldn't expose this environment variable to the public UX of Notion. (It bugs me that Rust exposes this for every program ever.) Maybe we can do something like unconditionally always generate a full backtrace (by modifying RUST_BACKTRACE to "full" on startup, but restoring it to its initial state whenever we shell out to another process? by using backtrace? by using failure? needs more investigation).

[dherman]

To clarify: unconditionally always generate a full backtrace, but NOTION_DEV just controls whether that only goes in a log file or also gets printed out to stderr. I 100% agree with you that we should generate this info in an error log file for diagnostic purposes; NOTION_DEV becomes more of a convenience for quick debugging by notion developers, for spitting out diagnostic info in CI, etc.

[dherman]

We could also investigate what human-panic is doing. I'm not sure it's the right abstraction for us to use but maybe it is. And even if not, we can learn from how they work.

[charlespierce]

We've cleaned up the "internal" errors, so closing in favor of #75 around how to get backtraces without RUST_BACKTRACE