Add signer publication delay

[lukasz-zimnoch]

Closes: #553
Depends on: #610

This PR introduces a delay mechanism that forces signers to wait an amount of time before publishing the signature for a given keep. The value of the delay is the product of the signer index and a constant step (5 minutes). So:

• member 0 doesn't wait and start the publication process immediately
• member 1 waits 5 minutes
• member 2 waits 10 minutes

This change should prevent signers to publish the signature at the same time. Publishing at the same time is not optimal as only the first transaction succeeds while the second and third revert and burn some gas.

[pdyraga]

We should now remove two logs saying signature for keep [...] already submitted. See what's happening in logs when the client is not the one that is submitting a signature:

2020-11-23T11:22:10.222+0100	INFO	tss-lib	party {1,}: signing finished!
2020-11-23T11:22:10.226+0100	INFO	keep-ecdsa	waiting [5m0s] before publishing signature for keep [0xe1C664a63BD1D017270aaE9bda45A776bA86a078]
2020-11-23T11:27:10.432+0100	INFO	keep-ecdsa	confirming on-chain signature submission for keep [0xe1C664a63BD1D017270aaE9bda45A776bA86a078]
2020-11-23T11:27:10.432+0100	INFO	keep-chainutil	waiting for block [17807] to confirm chain state
2020-11-23T11:29:45.889+0100	INFO	keep-ecdsa	signature for keep [0xe1C664a63BD1D017270aaE9bda45A776bA86a078] successfully submitted and confirmed on-chain
2020-11-23T11:29:45.889+0100	INFO	keep-ecdsa	signature for keep [0xe1C664a63BD1D017270aaE9bda45A776bA86a078] already submitted: [50b2c43fd39106bafbba0da34fc430e1f91e3c96ea2acee2bc34119f92b37750]

We do not need the last log, the one saying signature for keep [0xe1C664a63BD1D017270aaE9bda45A776bA86a078] successfully submitted and confirmed on-chain is enough. See it's emitted in confirmSignature function, so for the two cases I mentioned, we should be fine with removing logger.Info and leaving there just return.

[pdyraga]

When testing this PR, I noticed the party ID logged during TSS signing is different from signer index returned from the chain. I do not think it is blocking for this PR as the problem lies elsewhere so I opened an issue to capture it: #622

[pdyraga]

Scenarios tested:

• Happy path, signer with on-chain index 0 submits a signature to the chain, other clients confirm and exit the publication process.
• Signer with on-chain index 0 does not submit a signature to the chain, signer with on-chain index 1 does it after a delay. All signers confirm the signature on the chain and exit the publication process.
• Signer with on-chain index 0 does not submit the signature, all clients get restarted. Once they all appear online again, they start the signing process, publish the signature, confirm it on-chain, and finish the signing process gracefully.

[pdyraga]

A nice improvement to the code presented here would be to start the confirmation process if a signature appeared on the chain despite the fact the client is in the "delay publication" state. I do not think it's worth blocking because of that, and we can revisit this once we implement a new interface for event subscriptions (see keep-network/keep-core#491).

Captured it in the issue: #623