upgrade handler flag

[faddat]

Description

This PR adds an upgrade handler flag to Pylons.

It works like this:

Validators composing >2/3rds of votepower, set a halt height using the --halt-height flag.

Their daemons stop at that height.

the other nodes in the chain can no longer make a block, it's down at that block. 

they then restart the chain as:

pylonsd start --run-upgrade-handlers

This will allow pylons to upgrade, without the governance process. It's anti-pattern for the sdk, but I like the degree of control that it gives, especially during difficult situations. I'll probably upstream it.

---

Author Checklist

All items are required. Please add a note to the item if the item is not applicable and
please add links to any relevant follow up issues.

I have...

• included the correct type prefix in the PR title
• added ! to the type prefix if API or client breaking change
• targeted the correct branch (see PR Targeting)
• provided a link to the relevant issue or specification
• followed the guidelines for building modules
• included the necessary unit and integration tests
• added a changelog entry to CHANGELOG.md
• included comments for documenting Go code
• updated the relevant documentation or specification
• reviewed "Files changed" and left comments if necessary
• confirmed all CI checks have passed

Reviewers Checklist

All items are required. Please add a note if the item is not applicable and please add
your handle next to the items reviewed if you only reviewed selected items.

I have...

• confirmed the correct type prefix in the PR title
• confirmed ! in the type prefix if API or client breaking change
• confirmed all author checklist items have been addressed
• reviewed state machine logic
• reviewed API design and naming
• reviewed documentation is accurate
• reviewed tests and test coverage
• manually tested (if applicable)

[MikeSofaer]

IMO this is the way.

Ideally there would be a more fleshed out executive actions module that could halt the chain, do upgrades, etc.

[faddat]

Going to pound on the logic here and call it a night.

There are a bunch of reasons that you're correct @MikeSofaer -- this is better off as part of a set of tools.

[faddat]

nice

[mustafapylons]

Looks good to me.

[ThanhNhann]

With the magic, It does not show my info when I push the commit sir lol @faddat

[faddat]

What magic?

[faddat]

just fixing linting now

[nghuyenthevinh2000]

what I did?

1. make localnet-build: build a docker image of v0.4.2 pylons
2. docker container run -it --entrypoint /bin/bash pylons-node
3. bash test_node_deploy.sh (this runs 0.4.2 pylons binary)
4. wait for a while
5. ctrl + c to stop
6. git clone https://github.com/Pylons-tech/pylons.git
7. cd pylons & checkout upgrade-handler-flag
8. go build -o bin/pylonsd -mod=readonly ./cmd/pylonsd (this builds this newest version)
9. cd bin
10. ./pylonsd start --run-upgrade-handlers --upgrade-height 100

why docker?

so that environmnents for testing for all machine will be the same.

[hieuvubk]

So I think this pr work on my local test net.
And here are the steps to upgrade chain directly on the node without going through gov:

• Halt chain.
• Reinstall binaries
• Run cmd pylonsd start --run-upgrade-handlers=true --upgrade-height=[next-block-after-halt]
• If the same message below appears, the upgrade is successful

And I think this is just a temporary solution to reduce the waiting time (we are on testnet). Using gov is still a standard and safe way

cc @faddat @MikeSofaer @mustafapylons

[nghuyenthevinh2000]

Everything is cool, it is good to go.

[faddat]

nice reproducibility