Re-propose a block if sampling stalls.

[a-urth]

Sync period increased to ease simulation of the problem Steps to reproduce:

• start 3 nodes (since snowballK is 2 by default; more can be created, but it will just complicate scenario)
• create transaction on each node either before they are going to sync ("syncing...." message printed) or right after they synced

So what happens is all 3 nodes have different preferred blocks, since they create blocks based on transactions they have and they all have different ones. Which is fine, but whats not fine is that even after syncing transactions between each other and having all of the transactions on all 3 nodes, they aren't going to finalize anything, because there is no way any of them going to change preferred block. This is because node can only change its preferred block based on majority decision and not based on lack of one.

Note: Same can be achieved with default sync period (3s) and running 3 benchmarks at the same time on 3 different nodes. Best of all for me worked using 2 workers per benchmark, this way speed at which transactions are incoming is prioritized instead of volume.

Proposal: If there is no majority for snowballB number of ticks (one snowball round) - propose new block. This way nodes will propose new blocks based on new transaction they have and consensus will be reached eventually.

[a-urth]

Solution works like exactly what I was proposing. Works for me, can't reproduce problem in both ways. Awesome job!