Fix version logic when bumping major version

[tvernum]

When we are preparing to release a major version the rules around
"unreleased" versions and branches get a bit more complex.

This change implements the following rules:

• If the tip version on the previous major is a .0 (e.g. 6.7.0) then
  the tip of the minor before that (e.g. 6.6.1) must be unreleased.
  (This is because 6.7.0 would be "staged" in preparation for release,
  but 6.6.1 would be open for bug fixes on the release 6.6.x line)
  (in VersionCollection & VersionUtils)

• The "major.x" branch (if it exists) will always point to the latest
  minor in that series. Anything that is not the latest minor, must
  therefore be on a the "major.minor" branch
  For example, if v7.1.0 exists then the "7.x" branch must be 7.1.0,
  and 7.0.0 must be on the "7.0" branch
  (in VersionCollection)

Backport of: #38593
Partial Backport of: #38513

Co-authored-by: Jason Tedor [email protected]

[elasticmachine]

Pinging @elastic/es-core-infra

[tvernum]

This doesn't work because there's no way to know to tell the difference between these 2 situations:

1. current=8.0.0 , unreleased=[ 7.1.0 on 7.x , 7.0.0 on `7.0' ]
2. current=7.0.0 , unreleased=[ 6.7.0 on 6.7 , 6.6.1 on `6.6' ]

The fact that 6.7 is the last release in the 6.x line and therefore is on the 6.7 branch is (at this point in the version history) arbitrary. There is no way to know that we don't expect a 6.8.0, while simultaneously expecting that 7.1.0 should be followed by a 7.2.0

I think we just need to put a marker "end-of-6-development" somewhere, and VersionCollection seems as good a place as any.

[alpar-t]

Changes LGTM.

Are you sure we don't have to port any of this forward to make sure we don't run into it again ?

[tvernum]

Are you sure we don't have to port any of this forward

For the 7.x series we're good, because once we have a 7.1.0 (or even 7.0.1) we know that we've switched the "most recent released major" from 6.x to 7.x and that means the last minor of 6.x must be a maintence branch with an explicit branch name.

We will need to work out what solution we want for this when we hit the end of 7.x development, because, assuming our process is the same, that will have exactly problem of (for argument's sake) 7.8 is last minor in 7.x, but how does the 8.0.0 build know that there won't be a 7.9 ?

But I'm not sure if this fix is the one we want to copy to master. It's not terrible, but I think it's worth @elastic/es-core-infra discussing it before we do that.