DBFT reinitialization after chain height change

[roman-khimov]

If there was a new block accepted and added to the chain of consensus node, the consensus process should restart on this new height regardless of its stage (it's obsolete anyway). #641 fixed a part of this problem in that eventually (on timer expiration) the process will be restarted, but it can take some unpredictable time (especially with timer extensions like in nspcc-dev/dbft#24) and node can easily miss the next consensus round.

At the same time it shouldn't lead to node restarting consensus on every block added during the initial sync, so probably we also need to redefine consensus readiness from "minimum number of peers connected" to "no known peer has better last block index" (which can be a definition of node being in sync with the network).