Decide on an error reporting policy

[Jonas-Puksta-Sensmetry]

The goal is make error reporting more consistent, easier to maintain, and to produce more detailed diagnostics.
For now just deciding on a policy is enough without changing existing code, so that at least the new code gets the above benefits.

[andrius-puksta-sensmetry]

Rules of thumb. Apply by default, except in cases where there are good reasons not to.

1. Do not "repack" errors by unpacking them from one error just to create another. This loses the original error message (i.e. the Display impl of the original error will not be used). Instead, wrap each sufficiently distinct error cause (not type, these may overlap) in a separate variant. This allows to have different error messages for different operations, even though they might internally have the same error type.
2. All source errors should be annotated with #[source] when deriving thiserror::Error
3. #[source] errors should not be included in the error message, as they will be reported separately: - this is already done in CLI, but does not appear to work properly

• bindings will also have to be updated to include the whole error chain in the message reported to the other language

4. Avoid using #[transparent], instead include message of how/why the action that returned the error was taken
5. Use #[from] if the error can wrapped in a single way and doesn't need additional details from the call site. #[from] implies #[source].

[andrius-puksta-sensmetry]

Note: currently we use debug printing for reqwest(_middleware)::Error, because it does not include all details in its Display implementation. Notably, it includes the inner error (which includes the missing details) in its .source(), so we won't need to use debug printing when we start reporting #[source] properly.

[andrius-puksta-sensmetry]

General guidance on error reporting:

1. If the error is caused by a bug somewhere (e.g. function precondition was not satisfied), panic (e.g. explicit panic!, unwrap, expect, etc.)
2. If the error can't reasonably be handled by the application or by the user, panic. This applies to e.g. out-of-memory (allocation) errors (std already panics on e.g. Vec allocation failure).
3. In all other cases, don't panic. In particular, any user input must not cause panic not covered otherwise by point 2 (e.g. if the user requests to read a file so large that it exhausts memory, it does not need to be handled gracefully).

[andrius-puksta-sensmetry]

An alternative way: https://fast.github.io/blog/stop-forwarding-errors-start-designing-them/