Use thiserror consistently across the crate

[plafer]

From #55 (comment).

I advocate that we use thiserror for errors across the repo.

Pros:

• Implements std::error::Error for you
• Implements Display for you (with the attribute #[error("display string for error variant")]
• Doesn't appear in the public API, so we can stop using it at any point without breaking changes
• Convenience attributes, such as #[from] which implements a From for the variant that it's defined on (which plays nicely with the ? operator)
• Widely used, and well maintained (by dtolnay)

Cons:

• Doesn't work with no_std, only due to the fact that std::error::Error lives in std instead of core, but this is eventually going to change

Alternatives:

• We could go with anyhow or eyre instead if we want to write "one-off errors" (no enums defined) everywhere and lose the ability to match on specific error variants. We can also use both: thiserror for all library code, and anyhow in the binary or anywhere we're absolutely certain the error is only meant to be printed out to the user

[bobbinth]

For the node, I don't think we are aiming for no_std support - so, I think using thiserror is fine.

[bitwalker]

We use both anyhow and thiserror in the compiler, leaning more on custom error types via thiserror than anyhow, but I have nothing but good things to say about both projects.

Biggest downside of thiserror is definitely the fact that the Error trait is only in libstd, but once that changes it'll be borderline essential to use, since otherwise the boilerplate for error types is nuts.

[hackaugusto]

Just to clarify, the goal here is to use thiserror in addition to anyhow, correct?

[bobbinth]

Not sure of pros and cons - but seems like we should mostly lean on thiserror and use anyhow only in binaries?

[bitwalker]

I would only use anyhow in functions which join together different error types from the same crate. If you find yourself writing error types with multiple "#[error(transparent)]" variants, that's a sign anyhow::Error is a better fit there. Within a crate, it can still be useful to keep strongly-typed errors so that you can handle those errors. Once something is an anyhow::Error, it's a lot more awkward to handle errors directly, and more likely that they just get yeeted up the stack.