Add support for fetching & parsing the Tendermint version of a chain

[adizere]

Closes: #2301

Description

Adds version detection support for the Tendermint dependency. In Hermes logs, this appears as:

2022-06-15T09:25:08.592954Z TRACE ThreadId(25) parsed version specification for gaiad v6.0.4@305668ab9d962431c79d718bb0ffdeec77a46439 -> SDK=0.44.6; Ibc-Go status=Some(Version { major: 2, minor: 0, patch: 3 }); Tendermint=Version { major: 0, minor: 34, patch: 15 }

---

PR author checklist:

• Added changelog entry, using unclog.
• Added tests: integration (for Hermes) or unit/mock tests (for modules).
• Linked to GitHub issue.
• Updated code comments and documentation (e.g., docs/).

Reviewer checklist:

• Reviewed Files changed in the GitHub PR explorer.
• Manually tested (in case integration/unit/mock tests are absent).

[mzabaluev]

This could be problematic, since the -pre versions semantically precede the release without the pre suffix. So this is lossily bumping the version to a later one than what the module author intended.

[adizere]

We added this trimming of Prerelease version due to this issue: #1337 (comment).

The issue was that networks were using an RC instead of the stable release, e.g.

SDK module at version '0.42.0-rc0' does not meet compatibility requirements >=0.41.3, <=0.42.6

Which was fixed by trimming the Prerelease element. Not sure if you're hinting at a different issue than the one we noticed in the production signaled in #1337.

[mzabaluev]

The issue was that networks were using an RC instead of the stable release, e.g.

SDK module at version '0.42.0-rc0' does not meet compatibility requirements >=0.41.3, <=0.42.6

This semver check behavior is stricter than what I assumed. I expected that 0.42.0-rc0 does succeed 0.41.3 and precede 0.42.6, but would not meet this requirement: >= 0.42.0. Do pre-release suffixes make versions completely incomparable by the comparison logic?

Which was fixed by trimming the Prerelease element. Not sure if you're hinting at a different issue than the one we noticed in the production signaled in #1337.

Thanks for the exposition on this. A proper solution, I think, would be for the compatibility requirements to explicitly include any pre-releases they want to allow, but perhaps practicalities dictate otherwise.

[adizere]

Do pre-release suffixes make versions completely incomparable by the comparison logic?

We could give this a try in a small experiment. Not sure what you want to try exactly, but I managed to reproduce the original issue here: https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=c31232aaa272967f2979abf71e83f258

A proper solution, I think, would be for the compatibility requirements to explicitly include any pre-releases they want to allow, but perhaps practicalities dictate otherwise.

Indeed, it's not feasible for us to track all pre-releases and test with each of them individually. We assume that pre-releases have the same API as their corresponding release.

[mzabaluev]

Thanks for the playground; it appears that the semver crate does treat non-empty pre-release segment as not matching any comparisons with regular versions:

thread 'main' panicked at 'version 0.42.0-rc0 matching req >0.41.5', src/main.rs:14:5

The logic of VersionReq::match is poorly documented in semver docs, even though the Version type as such implements a total ordering that is documented to work in the way I described.
Then there is this:

Where the various tools differ in their interpretation or implementation of the spec, this crate follows the implementation choices made by Cargo. If you are operating on version numbers from some other package ecosystem, you will want to use a different semver library which is appropriate to that ecosystem.

[mzabaluev]

Good to go, with reservations I have filed in #2309. These, however, apply to more than the code introduced in this PR, and can be fixed later.

[adizere]

Excellent, thanks for filing 2309 and the great feedback here Mikhail, appreciate the level of details we went into!