Reduce error boilerplate using `thiserror` about acmed HOT 2 OPEN

I've started taking a jab at this, I've identified a few more problems that I didn't see before:

• There's a lot of type information lost in the current error handling. When handling. Each time an error type is converted using the ? operator, it is converted into a string. In my local draft, I've fixed this by having a big enum with the types to convert from kept in variants. All the From impls are generated by thiserror
• Context for errors is kept in the same String as the error itself, by using a prefix method, which prepends a string to the error message itself. This means that even with the changes I've made before, when using the prefix method, I have to convert the error to a generic string error type, loosing the type information again. There's crates specialized on adding context to errors, like anyhow.
• There's a gigantic amount of error sources that all get dumped into a flat error type. I'd think it would make sure to restructure this a bit and split them into a few smaller error types, similar to what we already have for AcmeError and HttpError, but to extend that to also add a few errors for stuff like config loading etc.

So, now with a bit of my findings documented, there's just one question I have: Do we want to keep type information of the errors we're wrapping? If so, the approach with thiserror I've started with sounds like a sensible option to me, but it's a lot more work to structure it properly. If not, we can get rid of nearly all of the error handling code if we just switch to anyhow.

from acmed.

Regarding the commit that just landed on main last night (e9522df), I think it'd make sense to push changes to a branch and open a PR, even when working on your own projects. This gives people the opportunity to provide feedback before things land on main, and it allows the CI to run, catching things one might have missed locally, such as the MSRV increase in df40cde.

from acmed.