Make certifying_eq/DKG always return?

[real-or-random]

Currently, certifying_eq, and thus the DKG, may hang forever. This makes sense in theory, but is not a very suitable model for implementations. (Assume you run this in a thread and the machine dies at some point... What now?)

We could do the following instead:

• Have a non-interactive certifying_eq_round or similar that simply returns to the caller with a sig. This is anyway more consistent with the other algorithms, for which we split non-interactive and interactive.
• Add a non-interactive wrapper for that for the DKG, that also just returns the signature (optional).
• Have a non-interactive certifying_eq_finalize that only checks the cert.
• Have a recpedpop_finalize algorithm that only does the following: If the caller gives us a DKG state and a cert (valid according to certifying_eq_finalize), return the shared public key.

This interface is a bit nicer, and it's compatible with the idea that the cert can be sent late, e.g., attached to signing requests. If you receive a cert late, you can simply call recpedpop_finalize at that point. (Instead of "feeding" it onto the incoming wire of certifying_eq, which you would have to do right now, so that the while loop can catch it.)

We could also consider returning the shared pubkey early. That may be convenient for callers who know what they're doing, but that's rather bit risky for those who don't... I don't know. I guess it's not necessary. In a singing request, you can use the setup_id to uniquely identify the setup. You don't need the aggregate public key for that.

[real-or-random]

I like the changes on master. I think this is solved.