[Draft] Make build.rs check error logging and chaining

[kaimast]

This PR adds a mechanism to ensure errors are logged and chained in the "correct" way.

The following two common issues are addressed:

• Full error information is lost by converting it into a string, e.g., anyhow!("my message - {err}")
• An error is logged without printing the full chain, e.g. warn!("{err}") instead of warn!("{}", flatten_error(err)).

Implementation Details

Similar to the locktick checks, these checks are performed at build type using the build.rs script. The code walks the syntax tree of every file to looks for the use of variables named err, e, or error. It then ensures the error is properly formatted or chained.

It will then print the offending location and line as an error, which can look something like the following:

error: snarkos@4.4.0: The following instances of improper error formatting were found:
error: snarkos@4.4.0:     • ./cli/src/commands/developer/scan.rs:275 -> anyhow!("Failed to fetch blocks range {request_start}..{request_end}: {err}")
error: snarkos@4.4.0: 🔴 1 error(s) were formatted in a way that may discard important context information. Chain errors via `anyhow::Context` instead.
error: build script logged errors
warning: build failed, waiting for other jobs to finish...

There are some cases where you want to concatenate error messages, e.g., sometimes we prefix a context such as [Gateway]. For these cases, the PR adds macros and helper functions to do this explicitly, such as bail_concat! and prefix_error. The latter changes the top-level error message, without discarding the error chain.

Finally, I also updated the locktick checks to use the same syntax tree approach. It is much cleaner and allows for more detailed error messages, such as the following:

error: snarkos@4.4.0: The following instances of improper locktick imports were found:
error: snarkos@4.4.0:     • ./cli/src/commands/developer/scan.rs:35 -> parking_lot::RwLock imported without a locktick counterpart
error: snarkos@4.4.0: 🔴 1 lock(s) do not have locktick counterparts (or vice-versa). This may break compilation and prevents locktick from working correctly.
error: build script logged errors.
warning: build failed, waiting for other jobs to finish...

Notes

• anyhow::Error has a built-in way to flatten errors. It uses the alternative formatting, i.e., {err:#}. However, that mechanisms uses colons as separators, and it does not work with thiserror types. See Display cause chain when alternate format is used dtolnay/thiserror#98 for more information.

[vicsn]

This should have had a discussed issue before we start writing code.

Full error information is lost by converting it into a string, e.g., anyhow!("my message - {err}")
An error is logged without printing the full chain, e.g. warn!("{err}") instead of warn!("{}", flatten_error(err)).

Can you give concrete examples of the difference in what is printed?