[DISCUSSION] Improve protocol voting timeline

[ilblackdragon]

Protocol voting as currently outlined in the specification has PROTOCOL_UPGRADE_NUM_EPOCHS=2 epochs post consensus on the new version (PROTOCOL_UPGRADE_BLOCK_THRESHOLD): https://nomicon.io/ChainSpec/Upgradability.html#consensus

This has historically proven to be too short of a time and led to sudden drop off of validators who hasn't upgraded . Additional date was added to delay the voting until a specified timeline in the release. This has it's own downside that there is no information onchain about upgrades until the specified date. This still has a property that validators who may want to observe how the vote is going will get caught by surprise at the moment of that date.

I suggest to change the announced date with release from when vote starts to earliest when vote goes into effect. in this case upgraded clients start indicating their version right away, while even if PROTOCOL_UPGRADE_BLOCK_THRESHOLD achieved before the date - the protocol takes into effect on the specified date. If PROTOCOL_UPGRADE_BLOCK_THRESHOLD wasn't achieved by then - new protocol only will update after it is + PROTOCOL_UPGRADE_NUM_EPOCHS.

We may also want to consider increase PROTOCOL_UPGRADE_NUM_EPOCHS as part of this to longer timeline, because now it only would be used if consensus wasn't achieved specifically by predetrimned the release date.

[VanBarbascu]

I like the idea of extending the upgrade grace period. We should keep PROTOCOL_UPGRADE_NUM_EPOCHS configurable to account for different release content priority. Perhaps it can be part of EpochConfig.