Design and implement updated error types for the ZKP module

[marsella]

The zero-knowledge proof module is pretty independent of the protocol implementations. It doesn't encode any basic knowledge of protocol-level entities like participants or participant IDs. I think there are only a few types of failures across the proofs:

• some input was bad and we couldn't generate the proof
• some randomness went wrong and we couldn't generate the proof
• the proof failed to verify because a check didn't pass
• the proof failed to verify because we tried to do some computation (in service of a check) and the computation failed
• we tried to deserialize a proof from a message and some of the fields were invalid

Someone else should think about this more carefully, but I think the top two map to InternalInvariantFailed and the bottom three to ProtocolError. However, since the proofs themselves don't know the participant ID of the verifier, they can't throw a useful protocol error; that field has to be filled in by the caller.

Proposed solution

I thought of a few potential ways to address this:

• we could add a whole error type for ZKPs that cover the above errors, with appropriate logs, and manually convert at every call site into the external-facing InternalError (side note: we might want to change that name)
• Since proving never results in a protocol error (only InternalInvariantFailed or maybe CallerError) we could have the prove method return an InternalError and the verify method return some other ZKP or crypto-module-specific error type, so we only have to manually convert at verification

This issue so far only addresses the ZKP module, but since that module calls into lots of other crypto-generic methods (e.g. sampling methods in utils.rs, curve point methods), if we decide to make a ZKP-specific error type we might want to actually have that be the error type for all the generic-crypto modules. In that case we might want to block this issue on #145.

Completion criteria

• Choose an approach. Document it in the comments and get feedback if possible
• Implement the approach, breaking into sub issues if necessary (e.g. if you make an all-new error type it will be better to review if you update the proofs one at a time in separate issues + PRs)