YAML test framework: simplify version node_selector

[ldematte]

Remove ranges and allow just current/original.

Node selectors with version ranges are used today just for mixed cluster/rolling upgrade tests, to filter out (or select) the new upgraded nodes that exhibit a change behaviour.
Therefore it is not needed to specify explicitly a version range: selecting nodes that have been upgraded (current) or not (original) is sufficient.

Today just current exists; this PR adds original (with one example usage) and removes the ability to select nodes based on version.

(Follows #103889, where we removed all version-based node_selectors but this one)

[mosche]

This makes sense to me @ldematte 👍 But please gather some more opinions :)
As a suggestion, how about using previous instead of the negated non_current?

[ldematte]

Naming is hard :)
In code, we current have "original" and "old" to describe the "not current" cluster. "Previous" can be confused with some -1 version (previous minor like 8.12 or previous major like 7). Maybe if we want to avoid the negation, original is a better choice.

[elasticsearchmachine]

Pinging @elastic/es-core-infra (Team:Core/Infra)

[ldematte]

As a suggestion, how about using previous instead of the negated non_current?

I will change that to original after merging #103889 - it makes more sense in the context of upgraded/mixed clusters. Wdyt @mosche?

[mosche]

Is this only for mixed cluster tests, @ldematte? Initially I was struggling to bridge the gap between original and current, but the more I think about it the better I like it 👍
Even better would be something like original (or also initial) and upgraded instead of current. That way both terms are not about a specific version, but more about the state in terms of upgrading.

[ldematte]

AFAIK, it has a meaning only in mixed cluster and rolling upgrade tests. I like the change to upgraded too - will have to be careful with that/do it in 2 phases as I think it is used in (and was introduced for) serverless.

[williamrandolph]

Just one question, but LGTM otherwise.

[ldematte]

I had to re-introduce the version matching for restCompat tests. Those test are a bit peculiar: they checkout elastic/7.17 to get the yaml files/specs from that branch, but run elastic/main test code.
So I added a check to see if we are in a restCompat tests, and only if we are, we do go down the legacy parser that support versions. This would prevent new usages of version-based selectors to sneak in, and also made removal once we switch to 9 (I have decorated the relevant methods with @UpdateForV9)

[ldematte]

Serverless tests fail for an unrelated, known issue: https://github.com/elastic/elasticsearch-serverless/issues/1461

[williamrandolph]

LGTM!