[TASK] In the worst-case scenario, ensure we pick a single validator as the governor (use their DKGId)

[drewstone]

Issue summary

We currently have an edge case where we don't reduce the n below 2. In reality, we should consider the case where everything fails and there is only 1 EOA signer remaining who becomes the next governor. This is good for liveness and then we can work to restart the keygen in the next round or sooner when this edge case happens.

Things that need to happen:

• Handling the case when we drop to t=0 n=1
• DKGGadget would cease to execute normally and instead we would fallback to the single signer keystore.sign(public, ...)

[drewstone]

@shekohex @1xstj re-discussing what was discussed at 6/22/23's Launch Readiness Sync on the topic of the fallback mechanism we want to support.

The only way we support reducing down to a single validator is if we make the # of misbehaviour reports required =t and not =t+1. This has theoretical security issues if we consider t malicious nodes, as they can report misbehavior of other nodes to seize control of the DKG. If we do choose this route we'd likely be better off removing ProposerSetUpdate logic and sidelining that.

On the other hand, we could consider combining/merging the RefreshVote with ProposerSetUpdate data. The main purpose being we shouldn't need to update the Governable.sol storage more than once, especially if we're already transferring the governor we should also update other metadata (proposer set metadata specifically). That would make the refresh vote composed as the following:

RefreshVote {
    nonce: u32,
    pubkey: [u8; 64],
    proposerSetRoot: [u8; 32],
    averageSessionLengthInMillisecs: u64,
    numOfProposers: u32,
}

Then we can still consider relying on such logic (majority vote for force changing governor's on applications) and do so with fewer transactions (1 each session).