[tool] Add initial gradle validation command

[stuartmorgan-g]

Adds a repo tool command to validate that all plugins set an explicit Java compatibility version, instead of using whatever the local toolchain happens to be (which creates the potential for issues like flutter/flutter#124839 where our CI passes but builds fail for some clients because our default is newer than theirs).

Currently that's all it checks, but we can add any other gradle best practices we want to enforce here in the future.

This also enables the new check in CI, and fixes all the violations it found.

Fixes flutter/flutter#124839

Pre-launch Checklist

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• I read the Tree Hygiene wiki page, which explains my responsibilities.
• I read and followed the relevant style guides and ran the auto-formatter. (Unlike the flutter/flutter repo, the flutter/packages repo does use dart format.)
• I signed the CLA.
• The title of the PR starts with the name of the package surrounded by square brackets, e.g. [shared_preferences]
• I listed at least one issue that this PR fixes in the description above.
• I updated pubspec.yaml with an appropriate new version according to the pub versioning philosophy, or this PR is exempt from version changes.
• I updated CHANGELOG.md to add a description of the change, following repository CHANGELOG style.
• I updated/added relevant documentation (doc comments with ///).
• I added new tests to check the change I am making, or this PR is test-exempt.
• All existing and new tests are passing.

[stuartmorgan-g]

This will obsolete #3712 if it's ready to land before that gets a no-test exception.

[reidbaker]

I know changing file names can be a pain but can we name this something more specific. I think we will have more gradle checks moving forward. Maybe gradle_conventions_check_command

[stuartmorgan-g]

I was assuming that future gradle checks would be added here; is there a reason we'd want new commands for those instead of having them all here? If you look at things like pubspec-check, we do a bunch of different checks related to the file in the one command.

[reidbaker]

So I had assumed that this command was only for the gradle files at the top of packages since that was what was parsed. Basically the implementation was the behavior you desired but the documentation was incorrect. Based on this update if all checks will live in this file then then the name makes sense.

[reidbaker]

This is not true based on the implementation. I think this will only impact topline gradle files and does not check gradle files in app.

Also from a structural perspective I think you might want to logically separate example gradle files from gradle files of plugins that are published.

[stuartmorgan-g]

I think this will only impact topline gradle files and does not check gradle files in app.

This is currently true, because the check I've added didn't seem important for apps. If that's not the case we can definitely change that.

Also from a structural perspective I think you might want to logically separate example gradle files from gradle files of plugins that are published.

Yes, that's why I have it only iterating over top-level packages, rather than setting the command to iterate over everything. My thought was that we could add example checks later, but I can definitely implement the structure for that now.

[stuartmorgan-g]

It now iterates over everything, and just skips the current check for examples, so it will be easy to add things for all gradle files later.

(Let me know if you want this specific check to run for examples; currently it's not even in the flutter template for apps.)

[reidbaker]

So I had assumed that this command was only for the gradle files at the top of packages since that was what was parsed. Basically the implementation was the behavior you desired but the documentation was incorrect. Based on this update if all checks will live in this file then then the name makes sense.