feat(replacements): add replacements:gradle-wrapper-validation-action

[mueller-ma]

Changes

See Readme at https://github.com/gradle/wrapper-validation-action for more information.

Context

Documentation (please check one with an [x])

• I have updated the documentation, or
• No documentation update is required

How I've tested my work (please select one)

I have verified these changes via:

• Code inspection only, or
• Newly added/modified unit tests, or
• No unit tests but ran on a real repository, or
• Both unit tests + ran on a real repository

[rarkins]

We normally don't want to do "replacements"
When the change is breaking. An alternative here is to met the user update to v3 and then migrate them

[mueller-ma]

Now the user needs to update to version 3 before the replacement happens.

[rarkins]

Is the intent to allow either 3 or e.g. 3.2.10? and not e.g. 3.2?

[HonkingGoose]

The code started with:

        "matchCurrentVersion": "3",

I asked if that would match all possible versions in the 3 range:

• feat(replacements): add replacements:gradle-wrapper-validation-action #31645 (comment)

Our developers docs list the rules for replacement presets:

Rules for replacement presets

1. Replacement PRs should ideally propose a replacement only once the user is on a compatible version, by specifying a compatible matchCurrentVersion constraint
2. If no compatible replacement upgrade is possible, it's acceptable to propose an incompatible one (e.g. a major version upgrade)
3. Replacements should update the user to the first recommended version of the new dependency and not include any new changes - whether breaking or not - if they can be avoided, in short: pin the new version

If possible, replacement presets should give the user a replacement version that is functionally identical to the last version under the old name.
We only want a user's tests to fail because of broken references to the old package name, and not because the maintainer(s) changed the behavior of the package.

The key phrase in the docs is:

Replacement PRs should ideally propose a replacement only once the user is on a compatible version, by specifying a compatible matchCurrentVersion constraint

So then the question is, is just being on any version 3 of the program good enough for a user to quickly merge the replacement PR? Or does the user need to be on the last version of the old package?