Signing protocol may halt

[kayabaNerve]

The signers will ensure they don't preprocess multiple times by:

• Creating the preprocess
• Saving they preprocessed
• Sending the preprocess

This prevents sending one preprocess, rebooting, creating a distinct preprocess, sending it, and then using the new preprocessing while everyone else received the original preprocess.

If the signing protocol hits a re-attempt, and then 34% of validators create the preprocess, save they preprocessed, and fail, the protocol will never be queued for re-attempt as we didn't achieve 67% participation.

We can cache preprocesses, allowing sending the existing preprocess multiple times, or we can allow multiple preprocesses where we're informed which preprocess is expected for us to use, and we simply don't yield shares if a different preprocess was expected.

The latter is the correct solution and should be feasible as the coordinator does tell us our own preprocesses. We just have to change the current behavior to rely on that.

Affects serai-processor-frost-attempt-manager and the DKG confirmation.

[kayabaNerve]

The new DKG confirmation code does handle this behavior correctly. It'll always send shares for attempt #0, only clear the reattempt message once the preprocesses have been sent, and does check it's producing shares for the expected preprocess.