Cosmos-sdk Issue for full Proto Migration: cosmos#5444

Context

When an upgrade fails due to a consensus failure, or for some other reason a validator causes is out of consensus (ex. running the wrong binary), it is sometimes useful to be able to revert the last committed block.

Acceptance Criteria

Given a user needs to revert a block
When they invoke their daemon with the --unsafe-retry-last-block (ex. xrnd start --unsafe-retry-last-block)
Then the state of the last committed block will be reverted and the daemon will try to reprocess that block

Context

The upgrade handler for the upgrade module is able to handle migrations that can happen within BeginBlock. Certain root multi-store migrations need to happen outside of BeginBlock - specifically renaming or deleting store keys. The basic support for doing this was added in cosmos#4724. This functionality needs to be integrated into the upgrade module.

Acceptance Criteria

Given that multi-store StoreUpgrades are needed and an upgrade is happening
When the new binary starts
Then the StoreUpgrades will be performed at the correct upgrade height before the ABCI app starts

Proposed Design

• In the upgrade.Keeper BeginBlock method, write a file $DAEMON_HOME/data/upgrade-needed.json file to disk with the upgrade plan serialized at panic time with the actual upgrade height written in the file in the case of time-based upgrades.
• Change the upgrade.Keeper SetUpgradeHandler` method to:

 	SetUpgradeHandler(name string, upgradeHandler types.UpgradeHandler, storeUpgrades []storytypes.StoreUpgrades)

so that whenever store key renames/deletions are needed they can be registered with the upgrade handler

• Add a hook to the upgrade module that configures BaseApp and the multi-store before starting the ABCI app. The multi-store upgrades should only be performed when there is an upgrade-info.json present and the version of the store matches the upgrade height in the json file. This will prevent store upgrades from happening too early.

Notes

• the current design of BaseApp.UpgradeableStoreLoader likely doesn't do what is required as this would require that the store upgrades are written to disk outside of the binary, presumably by the upgrade module. The actual behavior would likely be that the new binary contains a handler for the desired StoreUpgrades as mentioned above. Likely some hook between BaseApp and the upgrade.Keeper is neded.

Context

There are scenarios in which a planned upgrade handled by the upgrade module needs to be aborted. This could happen when:

• an error happens in the upgrade handler in the new binary and the upgrade can't complete
• there is a problem with the upgrade handler that causes a consensus failure (note that solving this also requires --unsafe-roll-back)

Acceptance Criteria

Given that an upgrade needs to be aborted because the new binary simply doesn't work right
When a user invokes the old binary with the --unsafe-skip-upgrade flag (ex. xrnd start --unsafe-skip-upgrade)
Then old binary will continue to operate as before and clear the planned upgrade from state

Summary

Ref: #29

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate contributors tagged
• Contributor assigned/self-assigned

Epic to track staking module improvements and development towards an independent staking module.

For tracking cosmos#5782

Check in with @aaronc on the structure / protobuf encoding for this module.

Cosmos-sdk issue for Full Proto Encoding: cosmos#5444

Context

• Currently the upgrade module can be tested only using simulation. I would like to propose integrating upgrade module with latest release of cosmos/gaia(v2.0.2). This would help in testing integration of upgrade module with the application.
• The same PR can help for cosmos/gaia after upgrade PR is merged to cosmos-sdk

Proposed Design

1. Integrate upgrade module with cosmos/gaia
2. Create 2 releases with different version in regen-network/gaia
3. Run a local testnet to check integration and working of upgrade module

@ethanfrey @aaronc