Test: automate upgrade test in ci

[yaruwangway]

Description

Closes: #2255

• The upgrade version is configured from reading app/upgrade/ and get the latest upgrade. The upgrade version will be used to propose upgrade proposal and setup cosmovisor dir. For example, if app/upgrade/ dir has two sub dir , v10 and v11, v11 will be used to propose ugprade and setup cosmovisor/upgrades/v11/bin/gaiad, and v11 will be used as upgrade name in the upgrade gov proposal.

• the upgradeFrom version is hardcoded (for each major release, please change here in the test.yml file.), the upgradeTo version is the PR branch.

The upgrade test workflow steps:
1. checkout pre-release if exist, otherwise checkout latest release.
2. checkout present pr branch ,build binary
3. checkout -,(back to latest release branch), build binary. (in step1, the binary is not build because if build there, it is lost in step 2)
4. checkout -, again back to pr branch to use the bash script in contrib for setting up the chain.

Pros:
for each major release, no need to update https://github.com/cosmos/gaia/tree/main/contrib/scripts/upgrade_test_scriptsscripts, and no need to update upgrade test in test.yml file.

Cons:
This PR contains many steps of setup, upgrade name is configured, this might have a higher chance of err when some setup breaks this configuration.

---

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, client, or state breaking change (i.e., requires minor or major version bump)
• Targeted the correct branch (see PR Targeting)
• Provided a link to the relevant issue or specification
• Followed the guidelines for building SDK modules
• Included the necessary unit and integration tests
• Added a changelog entry in .changelog (for details, see contributing guidelines)
• 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

[yaruwangway]

here upgrade version is configured from the latest upgrade in app/upgrades.

[mpoke]

@yaruwangway Could you please fix the indentation to avoid having the entire file modified (hard to see the diff)?

[yaruwangway]

if: env.GIT_DIFF will bring back later when pr get approved.

[p-offtermatt]

Nice, thanks for the work. Looks good to me.
I don't know where the appropriate place would be, but I feel like the behaviour should be documented somewhere, e.g. which folder is searched for releases, then the largest version number is used.
I'm only worried that if this behaviour is implicit, it might be confusing/silently break something at some point in the future.
If you know where an appropriate place would be, could you add a brief sentence about that?

Other than that, looks good!

[p-offtermatt]

might be worth adding a comment in the script what this loop does

[insumity]

Does the hardcoded v11.0.0 version imply we have to make a change in a new release?

[yaruwangway]

yes, here need to be changed every time when we release a new major release, I can add a comment here. presently this test only runs on PR trying to merge to main. This means the test is targeting at upgrading from last major release to present PR branch binary version. I also tried:

1. config v11.0.0 by latest release or pre-release, it is messy depending on latest release is before or after pre-release.
2. by using latest tag, somewhow this does not work in our repo, the latest tag is not the latest.

[yaruwangway]

Nice, thanks for the work. Looks good to me. I don't know where the appropriate place would be, but I feel like the behaviour should be documented somewhere, e.g. which folder is searched for releases, then the largest version number is used. I'm only worried that if this behaviour is implicit, it might be confusing/silently break something at some point in the future. If you know where an appropriate place would be, could you add a brief sentence about that?

Other than that, looks good!

good point, I also dont know where to add it, maybe in the internal repo release process ? cc @mpoke

[MSalopek]

Approve.

Maybe we should consider just downloading binaries instead of building from source. Using docker images with both binaries available could also be a good option.