Enable Gradle's stable configuration cache feature flag

[izeye]

This PR enables Gradle's stable configuration cache feature flag.

See spring-projects/spring-boot#32061

[shakuzen]

I ran this locally and checked the build scan, but I noticed we don't have the configuration cache enabled, so I'm not sure this makes any difference. If I try running the build with --configuration-cache then we get errors for the Nebula plugins we're using (see this build scan). I'm going to mark this as blocked until we first get the build running with the configuration cache, if that is something we will/should do. @jonatan-ivanov have we considered using the configuration cache before?

[jonatan-ivanov]

Feature Flag

As far as I see, this flag enables certain checks so that users will know about issues (get warnings) and can fix them before they get into trouble in a future versions regardless if they are using config cache or not (see here).

If this flag is enabled, we get some warnings (run ./gradlew build --warning-mode all to see them):

> Task :micrometer-registry-otlp:spotlessKotlinCheck UP-TO-DATE
Build service 'SpotlessTaskService' is being used by task ':micrometer-registry-otlp:spotlessKotlinCheck' without the corresponding declaration via 'Task#usesService'. This will fail with an error in Gradle 8.0. Declare the association between the task and the build service using 'Task#usesService'. Consult the upgrading guide for further information: https://docs.gradle.org/7.5.1/userguide/upgrading_version_7.html#undeclared_build_service_usage

(see build scan)

If we enable this flag (I'm ok with that), it will remind us every time we build that:

Deprecated Gradle features were used in this build, making it incompatible with Gradle 8.0.

Enabling Config Cache

Back then, this was a blocker (still is) that prevented us enabling config cache: hierynomus/license-gradle-plugin#198

Also, if I remember correctly, our config phase took around 1-2s back then so the amount of time we could have saved wasn't that much, the feature is "incubating" and not all the core plugins are supported (though I think this last one did not effect us), see here.

I've just checked a few builds and I see builds where the config phase takes more time (5-7s) but there are still builds in the 1-2s range, I did not investigate why.

We can enable it and suppress the errors but I don't think it is a good idea right now:

org.gradle.unsafe.configuration-cache=true
org.gradle.unsafe.configuration-cache-problems=warn

[shakuzen]

I assumed from the name and the location in the documentation that this flag will only do anything if you are using the configuration cache to begin with, but since that seems to not be the case, we can merge this without enabling the configuration cache. Thanks for explaining!