refactor: errors per module [WPB-14354]

[coriolinus]

What's new in this PR

Refactors core-crypto such that each logical module defines its own internal error type, and adds context whenever wrapping another module's error type.

• core_crypto::e2e_identity
• core_crypto::mls::client
• core_crypto::mls::conversation
• core_crypto::mls::credential
• core_crypto::mls
• core_crypto

Logical modules are assumed to be the set of peer modules at a particular level in the directory tree.

Draft notes

Test failures

I expect tests to fail for now, and often not even to build. I've intentionally avoided fixing up the tests until implementing all the error types, because otherwise there would just be too much churn. These will obviously be fixed before marking as ready for review.

Verbose {context, source} variants

There's quite a lot of manual coding here, and the usage pattern is ok, but it could be improved. I put together a macro library (context-err) a while ago which is intended to improve the situation, but I don't recommend it for production use yet. Right now the macro is very verbose, but still restrictive: it doesn't allow for boxing or 'static str contexts. We should think about whether we want to take this more in that direction.

General-purpose variants which should be collapsed

There are at least a few general-purpose {context, source} variants which could usefully be collapsed into more specific variants. I haven't yet done the analysis to identify all of these. In general the rule I will use is, if there are two or fewer distinct contexts in use, then they should just be variants of their own. If there are three or more, we should use the more general form.

Overall factoring

This whole pattern works well when each module defines its own types and operations. That's not the factorization in use here; modules might define impl blocks for half a dozen distinct structs. This means that, for example, basically every error type we've defined here has a nearly-identical Keystore variant, MlsOperation variant, associated helpers, etc. Multiple error types define independent ConversationNotFound, which is suboptimal. There's a fair amount of churn as identical error variants cross error type boundaries.

I strongly dislike this, and need to change it before seriously claiming that this is ready for review. But it's not yet clear what a better option would be. Here are a few:

• Refactor everything so that logical modules own and operate on internal types, whose details are not exposed to external code. This would be a Big Project.
• Define some kind of central LogicalError (bikeshed name) which has terminal error variants like ConversationNotFound, and then wrap it appropriately on its way through the various error variants.
• Just accept this mess as inevitable???
• Give up on this error-refactoring project and use CryptoError for everything, as is the status quo????

---

PR Submission Checklist for internal contributors

• The PR Title
  • conforms to the style of semantic commits messages¹ supported in Wire's Github Workflow²
  • contains a reference JIRA issue number like SQPIT-764
  • answers the question: If merged, this PR will: ... ³

1. https://sparkbox.com/foundry/semantic_commit_messages
2. https://github.com/wireapp/.github#usage
3. E.g. feat(conversation-list): Sort conversations by most emojis in the title #SQPIT-764.