CASSANDRA-21174: Prevent log-incompatible upgrades

[aparna0522]

patch by @aparna0522; reviewed by @krummas and @beobal

Thanks for sending a pull request! Here are some tips if you're new here:

• Ensure you have added or run the appropriate tests for your PR.
• Be sure to keep the PR description updated to reflect all changes.
• Write your PR title to summarize what this PR proposes.
• If possible, provide a concise example to reproduce the issue for a faster review.
• Read our contributor guidelines
• If you're making a documentation change, see our guide to documentation contribution

Commit messages should follow the following format:

<One sentence description, usually Jira title or CHANGES.txt summary>

<Optional lengthier description (context on patch)>

patch by <Authors>; reviewed by <Reviewers> for CASSANDRA-#####

Co-authored-by: Name1 <email1>
Co-authored-by: Name2 <email2>

The Cassandra Jira

[krummas]

code looks good, but tests need a bit of work

the new tests can be unit tests instead, and we should have a test which tries to actually commit a register/startup with a lower version.

[beobal]

There are a handful of other new test failures, but they're easily fixable:

InsertUpdateIfConditionTest (and friends)

This test is/was partially concerned with verifying the behaviour of certain statements when the cluster is being upgraded (see CASSANDRA-16415 for details). The way that the test fixtures are setting up ClusterMetadata to perform this verification is no longer possible after the additional constraints were added to Register (& Startup).
I've pushed a commit here which reworks the tests to achieve the same goal in a slightly different way.

ClusterMetadataTest

The failures here were in tests which assert that transformations with a min common version requirement can't be committed if the actual common version is lower. It was just the setup that was at fault as it was registering nodes with a higher version, before trying to add another with a lower version. As that is now disallowed, I just reversed the ordering, so that the node on the older version is added first. The only minor complication is that the first node becomes the sole CMS member, so assassinating it to reset the min common version isn't possible. So, instead the test now upgrades that node which ultimately has the same effect of raising the min common version. Test fix