NEP205: Delay voting for new version until a certain date and time

[nikurt]

See near/NEPs#205
This PR enables clients to extend the protocol upgrade window, but indirectly. This PR lets clients upgrade early but not announce the fact of the upgrade until a certain date in the future.

Normal upgrades:

• Clients will delay voting until a certain date.

Emergency upgrades:

• Voting for the new version starts immediately and a protocol upgrade becomes effective in 1-2 epochs.

[bowenwang1996]

Do we plan to manually set the upgrade time in code every time we do a new release for both testnet and mainnet? If so, how could we make sure that we don't forget to do it?

[bowenwang1996]

@nikurt please answer my question above #6309 (review)

[nikurt]

@bowenwang1996 sorry for missing the question.
Yes, we'll have to manually update it every time.
Also we can't assume that this date is always set, because emergency releases should leave the schedule empty.
I'm struggling to find a good way to automate the check whether the field was intentionally updated or intentionally not updated (multiple emergency releases in a row).

Every release requires a manual update of version in two Cargo.toml files. Maybe if we somehow move the schedule definition to Cargo.toml it will make the human error less likely? However it doesn't exclude the human error completely.

@abacabadabacaba do you have suggestions?

[mzhangmzz]

@bowenwang1996 sorry for missing the question. Yes, we'll have to manually update it every time. Also we can't assume that this date is always set, because emergency releases should leave the schedule empty. I'm struggling to find a good way to automate the check whether the field was intentionally updated or intentionally not updated (multiple emergency releases in a row).

Every release requires a manual update of version in two Cargo.toml files. Maybe if we somehow move the schedule definition to Cargo.toml it will make the human error less likely? However it doesn't exclude the human error completely.

@abacabadabacaba do you have suggestions?

Instead of only saving the current update time, how about store a dictionary from protocol versions to update times, so each time we upgrade, we have to add a new entry to the dictionary. For emergency update, the entry value will be None, but there still must be an entry.

[bowenwang1996]

@nikurt could you document this change in go/nearcore-release ?

[nikurt]

@bowenwang1996 documented