Properly handle ticks when waiting for In-Flight view to finish (#486)

* Synchronize Sync and view change proposal deliver to prevent a double commit

This commit fixes a bug in which a node is unaware of a proposal being committed
by the rest of the nodes, and it attempts a view change which fails, and triggers
a view change timeout, which in turn triggers a sync.

the asynchronous sync procedure may then commit that proposal, and the proposal
will later on be attempted to be committed again once the view change resumes
its operation, because the two procedures are parallel.

The easy and trivial way of solving this would be to make the view change
block until the sync process has ended. While this might work, it makes
the single-threaded view change be dependant on network I/O, which is
might slow down view change for other nodes due to votes being late.

Instead, this commit highjacks the view change commit process and:
1) Waits for any active sync to finish and prevents any syncs from occuring
2) Checks the latest sequence committed and if the proposal being attempted
   to be committed by the view change is stale, it calls sync which
   would return either the last proposal committed, or a later one.

Signed-off-by: Yacov Manevich <yacovm@il.ibm.com>

* Properly handle ticks when waiting for In-Flight view to finish

Due to a bug, When the view changer initializes an in-flight view it only waits for a single tick
before resuming view change standard operation.

Another part of the bug is that it anyway returns success, which in turn makes the sequence of the controller
be initialized to an old sequence.

Signed-off-by: Yacov Manevich <yacovm@il.ibm.com>

Co-authored-by: C0rWin <artem@bargr.net>

Author: yacovm