Minimize the amount of airgapped operations

[vshvsh]

All the ops are processed through the airgapped machine even if not exactly needed. Most operations in the FSMs do not require airgapped machine access.

The only steps that require it are:

1. delivery of private messages to the airgapped FSM
2. cryptographic operations using an airgapped secret
3. delivery of responses to the connected network

That means that the amount of airgapped ops in the current implementation can be radically reduced.

As an example, in the initial FSM for initiating a DKG there is a step that requires a participant to agree/decline to participate in a DKG (state_sig_proposal_await_participants_confirmation). It now requires a confirmation from an airgap; that needs to be changed so that agree/decline answer will come from a network-connected machine with dc4bc_d/dc4bc_cli running.

To implement this, a new UI should be implemented in dc4bc_d/dc4bc_cli which will allow for user input the event to an FSM on the same network-connected machine.

Another useful trick is to pack steps 1-3 into one trip to the airgapped machine and back.

How to change the operations:

StateAwaitParticipantsConfirmations handling should happen on a network-connected machine. Alternatively, it can be omitted at all, with refusal to participate further expressed in participant's silence instead of explicit decline message - which is fine but I'd prefer original design because of the more explicit, fail fast nature.

In StateDkgCommitsAwaitConfirmations message to FSM should contain the DKG parameters; the response should be a commit.

In StateDkgDealsAwaitConfirmations message to FSM should contain the commits; the response should be a set of deals (afaik that's how it works now).

StateDkgResponsesAwaitConfirmations should be refactored: default response of "everything is fine" is not needed, only response of "AAAAAAA everything is wrong" is interesting. So the "AAAAAAAA" response should be made an event that can happen on the reconstruction of public key step and makes FSM halt.

StateDkgMasterKeyAwaitConfirmations message to FSM should contain the deals; and the response should be a public master key or "AAAAAAAAAAAAAA".

StateSigningAwaitConfirmations handling should happen on a network-connected machine.

StateSigningAwaitPartialSigns message to FSM should contain the bytes to sign; the response should be a partial signature.

StateSigningPartialSignsCollected handling should happen on a network-connected machine.