feat (tests): enable multiple upgrades for automated upgrade tests

[MalteHerrmann]

Description

This PR does the following

• introduces the option to have multi-step upgrades during the automated upgrade tests
• enables to also include versions in testing that don't have the submit-legacy-proposal command (Evmos < v10.0.0)
• use custom pruning settings for the upgraded nodes

In order to run a sequence of version A to version B to version C, the syntax is as follows:

make test-upgrade INITIAL_VERSION=A/B TARGET_VERSION=C

The following commands can be tested (checkbox indicates if they work as expected):

• make test-upgrade INITIAL_VERSION=v10.0.1
• make test-upgrade INITIAL_VERSION=v10.0.1 TARGET_VERSION=v11.0.0-rc3
• make test-upgrade INITIAL_VERSION=v10.0.1/v11.0.0-rc1 TARGET_VERSION=v11.0.0-rc3

---

Closes ENG-1388

[linear]

ENG-1388 Adjust Upgrade Test Suite to allow for upgrading a series of more than two upgrades

Currently only one-step upgrades are possible (e.g. v10.0.1 > v11.0.0-rc1).

In order to test certain cases regarding testnet upgrades it would be necessary to replicate multi-step upgrades.

[Vvaradinov]

tACK. Great work on this @MalteHerrmann this will really simplify upgrade testing!

[GAtom22]

tACK! Great work!! Left a small typo fix.
Also, I noted that running the make test-upgrade command runs all the tests on the e2e package. Not sure if this is intended, but refactoring the test-upgrade instruction on the Makefile to this (only last line changes) only runs the automated upgrade test and shows the logs of the upgrade on real time (at least for me, using Ubuntu)

test-upgrade:
	mkdir -p ./build
	rm -rf build/.evmosd
	INITIAL_VERSION=$(INITIAL_VERSION) TARGET_VERSION=$(TARGET_VERSION) \
	E2E_SKIP_CLEANUP=$(E2E_SKIP_CLEANUP) MOUNT_PATH=$(MOUNT_PATH) CHAIN_ID=$(CHAIN_ID) \
	go test ./tests/e2e -v -run ^TestIntegrationTestSuite$

Another nice-to-have would be to extend this functionality to any number of upgrades. For example, I would replace INITIAL_VERSION and TARGET_VERSION with VERSION_SEQUENCE.

VERSION_SEQUENCE=<initial_version>/<1st_upgrade_version>/<2nd_upgrade_version>/<target_version>

But this is not a priority right now, and I understand the refactor would take some time. Just mentioning as a nice-to-have

[MalteHerrmann]

Another nice-to-have would be to extend this functionality to any number of upgrades. For example, I would replace INITIAL_VERSION and TARGET_VERSION with VERSION_SEQUENCE.

@GAtom22 it is already possible to include any number of upgrades, they just have to be separated by a forward slash - so e.g. make test-upgrade INITIAL_VERSION=v9.1.0/v10.0.1/v11.0.0-rc1 TARGET_VERSION=v11.0.0-rc3 works

I also thought about refactoring the variables to an upgrade sequence but saw the advantage with keeping the target version separate. The advantage is that users can just leave it empty and know the local codebase is used and don’t have to remember the exact syntax e.g. to put latest at the end of the sequence: v9.1.0/v10.0.1/latest.

What do you think?

[codecov]

Codecov Report

Merging #1283 (4adb8e0) into main (efe9cc7) will decrease coverage by 2.81%.
The diff coverage is 12.50%.

❗ Current head 4adb8e0 differs from pull request most recent head 80f3b50. Consider uploading reports for the commit 80f3b50 to get more accurate results

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1283      +/-   ##
==========================================
- Coverage   76.28%   73.48%   -2.81%     
==========================================
  Files         149      153       +4     
  Lines        8304     8639     +335     
==========================================
+ Hits         6335     6348      +13     
- Misses       1775     2095     +320     
- Partials      194      196       +2     

Impacted Files	Coverage Δ
tests/e2e/upgrade/govexec.go	0.00% <0.00%> (ø)
tests/e2e/upgrade/manager.go	0.00% <0.00%> (ø)
tests/e2e/upgrade/utils.go	24.52% <57.14%> (ø)
tests/e2e/upgrade/node.go	0.00% <0.00%> (ø)