imp: investigate why upgrade-client halts gaiad

[rnbguy]

Closes #177

• updates CI dependencies (gaia, hermes, cometbft, grpcurl, rust toolchain).
• in case of failure, prints last 200 lines from the logs from gaia, basecoin, cometbft.
• uses github workflow concurrency option.
• uses actions-rust-lang/setup-rust-toolchain to setup rust.
• implements HealthService::get_syncing.
• rename one-chain script to one-chain.sh.

[rnbguy]

Looks like, there is consensus failure at gaiad chain (ibc-0)

UPGRADE "plan" NEEDED at height: 144:  module=consensus stack=goroutine 132 [running]:
runtime/debug.Stack()
	runtime/debug/stack.go:24 +0x65
github.com/tendermint/tendermint/consensus.(*State).receiveRoutine.func2()
	github.com/tendermint/tendermint@v0.34.21/consensus/state.go:732 +0x4c
panic({0x1949de0, 0xc003c99d30})
	runtime/panic.go:838 +0x207
...

[rnbguy]

Latest changes now log the error directly on workflow.

cc @ljoss17

[rnbguy]

The error is coming from cosmos/cosmos-sdk/x/upgrade/keeper/abci.go#L79.

That means the upgrade plan does not set any handler. We are using the default plan as the plan name. Should this be anything specific for client upgrade?

[rnbguy]

We need to recompile the binary with a handler for the plan. I think it'll be fine to cancel the software upgrade somehow. There is a subcommand gaiad tx upgrade cancel-software-upgrade - but it doesn't work.

[rnbguy]

It looks like the upgrade-client test is meant to halt gaiad after the upgrade height. So, this script must be executed at the end of our e2e tests.

We may only run the grpc-service after it, as it doesn't involves gaiad.

[seanchen1991]

Looks good. Makes sense moving the upgrade client test to the end of the testing order 👍