Explicitly use JDK 17 through gradle toolchains

[DavidFair]

Changes
Pins the implicit JDK version to 17 (based on our CI settings) to avoid gradle sync errors with 8.x
This is because Gradle has bumped the DSL to 1.8 with version 8.x, so it highlighted the implicit mismatch going on

Issues
Fixes #2495

[nielsvanvelzen]

Gradle 8 not working is actually because of a bug in AGP that I believe is fixed in the next version so I decided to wait for the next AGP version instead. We don't really need Gradle 8 features right now.

[DavidFair]

Do you want me to drop the gradle upgrade?
I think the JDK pinning is still worth it, since the CI runs against 17, and this makes it expicit what we target

[nielsvanvelzen]

I've read a bit about Gradle toolchains and I now agree that we should indeed start using them so everyone is always using the same JDK version. I'm not a fan of the duplicate configurations so my proposal is to either use the buildSrc folder or a allprojects/subprojects config block in our root build.gradle.kts file.

[nielsvanvelzen]

Sorry for the long wait. I didn't like the way this PR made it's changes, which is not your fault but just how Gradle works.

I have a much simpler way to set the Java versions for the Kotlin&Android plugins from the root build file which I've pushed to the Renovate PR (#2495). I've also kept the target at Java 1.8 because older Android versions cannot read newer Java bytecode. Compiling with a newer Java version is fine though.

If you'd like you can rebase this PR on top of master so we can still merge the changes for the shared Android SDK numbers (those would go in the main build file now) and possibly the toolchains too. My apologies for taking a few weeks and redoing the primary part of your PR.

[DavidFair]

@nielsvanvelzen no problem, I understand gradle making things interesting

The diff now boils down to:

• Moving our jdk (pinned to 1.8) into the versions catalogue
• Explicitly specifying our toolchain is 17 to match the CI
• Using the Plugin mechanism to remove the duplicated SDK levels for Android targets I've dropped this as I've seen the simpler solution you ran with 👍

So I just want to check if you want all of these commits, or if you want some dropped?

[nielsvanvelzen]

Looks good, my only suggestion would be to not use the version catalog for those versions because they won't be updated by Renovate and they also need to be changed in the GH workflows when we update them. Putting something in the catalog creates the assumption that it's the "source of truth" (which it is for all other stuff right now).

[DavidFair]

Do you want me to drop the commit moving them into the catalog, or put them somewhere else?

[nielsvanvelzen]

Just leave both versions hardcoded in the build files

[nielsvanvelzen]

Thanks!