Pin gradle version used in Github Action workflows

[ansoncfit]

Apparently the default gradle version used in Github actions switched to v8.0 when it was released three weeks ago. Our workflows started failing around then with messages like:

Welcome to Gradle 8.0.2!

FAILURE: Build failed with an exception.

* What went wrong:
org/gradle/api/plugins/MavenPlugin

Before this change, our most recent successful workflow run used gradle v7.6. This PR pins the gradle version used in our workflows at v7.6.1, using the gradle-build-action plugin. It also removes our custom gradle caching; gradle-build-action handles caching itself and recommends not caching gradle with actions/cache because of possible interference.

We will need a similar change to fix the CodeQL action, but I am not familiar with the autobuild command used there.

[trevorgerhardt]

If we have a specific Gradle version that we need to use should this be defined in the project itself instead? That can be done using Gradle Wrapper. This would solve the CodeQL issue.

[abyrd]

It looks like one of the plugins we were using was just incompatible with Gradle 8. Rather than pinning to an older version, we can just update the build config to work with newer versions of Gradle.

The plugin in question is the one that makes "shadow jars" which we are in the process of phasing out (illustrated in #760) but all we need to do is bump the plugin version in the mean time.

Updating the Gradle config also has the advantage of working with any other action performing a build using the latest Gradle version, such as the currently failing CodeQL action.

Besides allowing you to pin the gradle version, the gradle-build-action used in this PR (866) also automatically handles gradle dependency caching. The latest version of the setup-java action, which we already use and is authored by GitHub itself, can also perform build tool dependency caching. I have updated the configuration to use this auto-caching.

Gradle was warning about some things that will be deprecated in 9.x too, so I fixed those.

I have put these changes in a separate PR #867.

Updating my local Gradle installation lands me on version 8, so I'm happy to just align local builds with the version actions is using. About defining the Gradle version in the project itself: personally I think it's sufficient to state in the README which Gradle version we're currently using, or just state that we align with the latest major version. The Gradle docs do favor the "gradle wrapper" approach but I've always avoided this system of checking in generated shell scripts that download and install separate per-project copies of a build tool. If all we need to do is update the gradle config from time to time to ensure it's compatible with more recent versions, I'd like to keep it simple and leave the wrapper scripts out.

Basically I'm quite skeptical of a lot of things about Gradle, and the main or only reason we used it was because it allowed us to set the artifact version programmatically in a way compatible with continuous delivery (instead of the horrible Maven release plugin running Maven N times and having to keep version strings perfectly in sync with git tags etc.) These days we could do CD-friendly versioning in Maven but the Gradle build is already written and working, so as long as all it needs is a little tweak here and there over time we might as well keep using it.

[ansoncfit]

Superseded by #867. While we might generally prefer to pin to old versions, only a few simple changes were required to update to the recent gradle version.