Use new implementation of Maven version standard

[amazimbe]

What are you trying to accomplish?

Update Maven to use the newly implemented maven version standard: #10524

I added a new implementation of the maven version standard in PR #10524. However, to reduce the size of that PR I decided to create a separate PR where I can integrate the new version implementation.

Fixes incorrect version precedence and adds extra tests for version comparisons.

Anything you want to highlight for special attention from reviewers?

The maven spec: https://maven.apache.org/pom.html#version-order-specification is not 100% compatible with the implementation we had before. For example, in the previous implementation, any versions with qualifiers like 'pr', 'pre' or 'dev' were considered prereleases. The maven spec only mentions "alpha", "beta", "milestone", "rc", "cr" and "snapshot" as having lower precedence than ("" | final | ga) i.e. as potential prereleases.

In my view, it's better to strictly follow the spec since standardising is one of our goals. Therefore, I have removed the other tokens from the previous implementation that were being treated as prereleases. However, this could be a breaking change for some users who might expect versions like 1.2.dev to have lower precedence than 1.2.dev, for example.

I've also had to remove some code and update tests to do with dynamic versioning e.g 2.+. This is a gradle feature that the maven specification doesn't support.

Finally, in order to test the new implementation thoroughly, I've grouped similar test inputs together and I loop through these lists to avoid having to manually type in the test cases individually. Inevitably, that's coming up as a huge diff in the test files.

How will you know you've accomplished your goal?

Checklist

• I have run the complete test suite to ensure all tests and linters pass.
• I have thoroughly tested my code changes to ensure they work as expected, including adding additional tests for new functionality.
• I have written clear and descriptive commit messages.
• I have provided a detailed description of the changes in the pull request, including the problem it addresses, how it fixes the problem, and any relevant details about the implementation.
• I have ensured that the code is well-documented and easy to understand.

[amazimbe]

@abdulapopoola Regarding use of a feature flag, I find the changes I've had to make quite minimal and not complex. Personally, I'd prefer to just do some additional manual testing. I fear a FF will make the code unnecessarily complex. Let me know your thoughts.

[amazimbe]

This is ready to review. The failing test needs to be updated in the smoke tests repo and I'll open a PR in that repo.