Simplify the way that signatures are collected

[quantumagi]

See #281

[dangershony]

Please describe the purpose and behaviour of this class in details, its clear it provides signatures but from who and how are the keys provided?

[quantumagi]

The keys are provided by the API call that activates federation. The purpose of the class is in the associated issue. I will add the detail to the class.

[dangershony]

@quantumagi please describe again the intention behind this change.
And I suggest you verify it does not break the current cross chin transfer as we just got ti to work.

One thing I don't get here is why do you need to pass signature information between the main and sidechain nodes (the two nodes connect to each other via api), signature material is passed around int he p2p payloads.

[quantumagi]

@dangershony, let's keep this PR on hold until after the release.

There is no intention to pass signatures between main and sidechain nodes. The plan is to replace the P2P calls with API calls (or wait for the P2P results) to support the following simplified synchronous workflow:

e.g. a new SignAndBroadcastMethod could do the following:

• Build a transaction
• Passes the transaction from leader to other sidechain members via parallel synchronous calls for signing). Wait for the results up to a max of a few seconds.
• Broadcasts the transaction if enough signatures were collected.
• This will require a quorum to be online simultaneously but should not be too big an ask.

This way there is no need to reserve UTXO's in the current way. We simply build, sign and broadcast in a single step.

[bokobza]

Locking so it doesn't go in by mistake.