Leader blocksync

[charithabandi]

Two mechanisms are used to prevent the leader from committing a block at an already finalized height:

1. Manual checkpoints: The leader can be configured with a checkpoint height, which is the
   height the leader must sync to before proposing blocks. The node operator should set the
   checkpoint height based on the network's best height.
2. Validator feedback: If the leader proposes a block at an already finalized height, validators
   will respond with a NACK, indicating the leader is out-of-sync. They can provide an OutOfSyncProof
   as evidence, including the BlockHeader and the leader's signature of the block the validator is on.
   This forces the leader to catch up to the validator's block height before proposing blocks again. This
   corrective mechanism allows leader to eventually converge to the best height.

However the nodes can still end up in these weird race scenarios where majority of Validators are in-sync with the leader, but not with the Validator with BestHeight, and the Ack's from the out of sync validators might end up reaching the leader faster than the OutOfSync NACK, eventually making the leader to commit the block. But the situation is not unrecoverable, leader and these Validators can always be wiped out and restarted to the correct state.

[jchappelow]

When this merges we need a descriptive commit message, which actually would be good for the PR description too. ;)

[jchappelow]

LGTM, but might be a little last minute for a beta.2. What's your feeling about it @charithabandi ?

[charithabandi]

I am fairly confident, ran lots of tests for various sync scenarios.