Upgrade Checkstyle integration test target 10.14.0 -> 10.21.1

[rickie]

Suggested commit message (similar to the previous one):

Sync Checkstyle integration test (#1425)
    
Summary of changes:
- Update `checkstyle-init.patch`. 
- Update `checkstyle-expected-changes.patch`.
- Update `checkstyle-expected-warnings.txt`
- Test against version 10.21.1 rather than 10.14.0.

Or my slightly preferred alternative:

Sync Checkstyle integration test (#1425)
    
By updating and testing against 10.21.1. 

[github-actions]

Looks good. No mutations were possible for these changes.
Mutation testing report by Pitest. Review any surviving mutants by inspecting the line comments under Files changed.

[rickie]

Hmm, this one is unexpected, if you don't recognize this one, I'll try to remove it @Stephan202 😄

[Stephan202]

This is a change in the patch context, not a change in the changes made by the patch. So this is not unexpected 👍

[rickie]

/integration-test

[github-actions]

Looks good. No mutations were possible for these changes.
Mutation testing report by Pitest. Review any surviving mutants by inspecting the line comments under Files changed.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[Stephan202]

Suggested commit message:

Upgrade Checkstyle integration test target 10.14.0 -> 10.21.1 (#1425)

(This phrasing is a bit different from what we did before, but if we start to file this kind of PR more often, then the summary messages will be more informative.)

[Stephan202]

This is a change in the patch context, not a change in the changes made by the patch. So this is not unexpected 👍

[rickie]

Instead of target we could say tag? 🤔

[Stephan202]

Well, the integration test targets a specific Checkstyle version. The specified tag is the test target.

[mohamedsamehsalah]

Thanks for the summary, LGTM 🚀

I also prefer the alternative message 😄

[mohamedsamehsalah]

I meant to approve ✅

[rickie]

@Stephan202 Two questions;

• As we are going to add quite a few PRs related to the integration-tests, I think it'd be a good idea to add a separate label for it.
• The Checkstyle test shows some JDK related error all the way at the end of the test. What do you think about adding a simple check in checkstyle.sh that validates you're not using an JDK higher than 17? As that doesn't give errors for me.

[Stephan202]

Re 1: not opposed, but as a non-maintainer reading the release notes, I'm not sure I'd care much about the details of our testing setup. We could of course introduce a separate label and then map it to the same release notes section. If you think that helps with filtering: works for me.

Re 2: we'd have to check whether this is compatible with GitHub actions, but perhaps it'd be even nicer if stuff "just worked", like this. The alternative is to parse mvn -version output and compare version numbers (possibly also for Maven): possible but not trivial. (But perhaps sort -h works well enough, didn't test.)