Head input chain offset

[ranchalp]

When a participant starts an f3 instance, it needs to determine whether it wants its proposal to contain from baseChain up to the head input chain it locally keeps in EC, or some prefix of it (i.e. offset it by some epochs). Although this may delay latency on the head tipset, it helps reduce latency and reach agreement faster on the EC instance. This is closely related with #173.

[ranchalp]

In pair with decision on #173 to wait for 2 epochs from the timestamp on the latest finalized epoch, the participant sets as proposal for the new f3 instance the following:

• Let $baseChain$ represent the finalized chain up until the latest finalized f3 instance.
• Let $ECChain$ represent the current heaviest EC chain according to the participant (that extends $baseChain$ by design)
• Let $e'$ be the epoch at which the participant is starting the new f3 instance (following decision on When to start an f3 instance #173 , $e' >= baseChain.head().epoch + 2$).

Then:

• If ECChain.head().epoch < e', participant sets its proposal to ECChain
• If ECChain.head().epoch = e', participant sets its proposal to ECChain[-1] (remove the head tipset, from the current epoch e')
• ECChain.head().epoch cannot be > e' by design (e' is the current epoch)