SigSubmission node-to-node mini-protocol

[coot]

We need to swap tx-submission protocol for one that:

• the client requests signatures,
• allows for a timely demotion

A good candidate is the object-diffusion, although it requires some modifications as it doesn't fulfil the second condition.

Detailed Plan

• Adop object-diffusion, drop the initial message as SigSubmissionV2 protocol, e.g. MsgInit - as we don't need it.
• The client side needs to be able to timely terminate the protocol. object-diffusion doesn't allow that because it has a non-blocking MsgRequestObjectIds with an infinite timeout.
• Implement client-side application analogous to V2.txSubmissionInbound
• Implement server-side application analogous to [txSubmissionOutbound]
• Wire the new protocol using a new NodeToNodeVersion.
• Update the CIP#137

Inbound application

Inbound application should be analogous to V2.txSubmissionInbound. One difference is that now the inbound side must receive ControlMessageSTM m. (Note: in the txSubmission case it is the outbound side that receives ControlMessageSTM m). When the client is in control it should read ControlMessageSTM and check if it is supposed to Terminate. The SigSubmissionV2 from https://github.com/IntersectMBO/dmq-node/tree/coot/sig-submission-v2 has one semi-blocking call MsgRequestSigIds which can block for at most 20s, the outbound side must make sure the other end receives the response within that time - we cannot have an unbounded blocking operation since the client wouldn't be able to timely terminate if requested by the outbound governor via ControlMessageSTM mechanism.

Outbound application

Outbound application should be similar to [txSubmissionOutbound], but it must not receive the ControlMessage STM (ouroboros-diffusion only supplies it to the clients which are governed by the outbound governor).

[coot]

I started hacking on this issue in the coot/sig-submission-v2 branch. It fullfils the first two bullet points from the plan above.