Switch to `thiserror` or similar

[expede]

NB: Feature requests will only be considered if they solve a pain or present a useful refactoring of the code.

Summary

Problem

rs-ucan today doesn't provide descriptive errors

Impact

It's hard to debug when integrating rs-ucan into applicatons, and makes it difficult to provide good error messages to users.

Solution

Switch from anyhow to thiserror or similar. The general guidance ([even metioned in the anyhow README) is that anyhow is great for applciations (where you don't expect to recover the error), and thiserror is best for libraries because it gives you more detail about what went wrong.

The trade off is that thiserror involves more manual threading through of error structs.

Detail

@blaine ran into this while building the Fission server.

Coda

First off, thank you so much to the miantainers of rs-ucan for the work thus far. anyhow was probably the fastest & most pragmatic way to get things running.

[cdata]

Sounds good to me, contributions welcome here!

[cdata]

Anecdotally, we use thiserror in Noosphere (so soft preference for that crate)

[FintanH]

Heya :wave: I'd be down for taking on this task to help out so I can peruse the library while also helping out :blush:

Before I would start I would ask what style of error management you would prefer in the library. On one end of the spectrum we could provide the kitchen-sink Error which captures all the error variants in a global error type, an example of this would be git2::Error. On the other end of the spectrum, we have very fine-grained errors types, essentially one for each function (this kind of approach is described in this post). Then somewhere in the middle, errors are grouped by some common components and aggregated in parent components, for example, mod foo and mod bar have their own Error types, and then top-level functions in lib.rs would have an Error type that has variants for foo::Error and bar::Error. Choosing what granularity in this scenario is probably the trickier part and requires on-the-fly judgement :)

In an ideal world, I'd go for the fine-grained approach as much as possible but tend to end up writing error code in the middle of the above spectrum. I don't really like the kitchen-sink error because it becomes really hard to tell where your errors are coming from.

Let me know what you think :grin: