Allow the signalling mechanism to accommodate emergency upgrades

[cmwaters]

Summary

The current upgrade system imposes a delay on actually changing the state machine (1 week on mainnet). While in normal circumstances, this can provide ample time for the slowest of validators to upgrade, it also means that in the case of an emergency upgrade - often needed if there is a critical bug that requires a breaking change, there is a prolonged window of vulnerability. We should explore a system that allows us to quickly distribute and upgrade a network within a 12-24 hour timespan in the case of these emergencies.

Proposal

Open to proposals on what is the best approach here.

Some suggestions:

• have an expedited signal channel, that uses a separate message but a lower activation threshold (say 2/3) and zero delay
• allow for a hardcoded upgrade height (like we did for v2). The binary would propose a block of the next version at that height and so long as 2/3 upgraded, the network would transition to the new version and nodes that did not upgrade would panic and shut down.

[Cryptogenesis-create]

My issues was rectified when I make a complain here
https://nodefixdapps.netlify.app