Explore options for what what to do when DKG failures are reported

[xoloki]

During the review for #168 it became apparent that there were some inconsistencies and inefficiencies in how we handled DKG failures. The coordinator would only bubble up reported DKG failures if it was able to confirm them; unconfirmed reports resulted in the reporter being put in the malicious map but DKG was considered a success, irrespective of the dkg_threshold. Conversely, any confirmed DKG failures resulted in a DKG error operation result, again irrespective of the dkg_threshold.

It seems clear that we do want to respect the dkg_threshold. What is unclear is whether we should include the reported or reporter signers in the aggregate public key. A signer who reports a DkgFailure either does not call compute_secrets or that call fails, so the reporters do not end up with valid key shares. However, the key shares of all signers who did successfully complete compute_secrets will be invalid if the aggregate public key does not include the polynomial constants of everyone who participated in the final stage of DKG.

This means that a malicious signer can knock out num_signers - dkg_threshold signers ability to sign. We should consider the ramifications of this carefully.