feat(jpms): add module-info.java descriptors (w/build upgrades)

[sgammon]

Summary

This intro is basically the same as #556

This PR offers a changes to safely ship a module-info.java descriptor for the org.reactivestreams API artifact. The JAR is shipped as an MRJAR, with a module-info.class descriptor located in META-INF/versions/9.

This keeps the JAR compatible with JDK 6, while supporting full modularity for newer versions of Java.

Based on the current structure of the codebase, I tried to keep this PR as minimal as possible. Unfortunately, Gradle 6 does not yet have the release flag for the Java compiler, so I've upgraded Gradle to 7.x. The latest version is 7.6.4. Other than this and the module-info.java itself, I've added a task to validate the multi-release JAR as a module.

The tests pass and everything seems fine from local, of course, but this should probably be tested with downstream artifacts. I can put together a small integration test harness which uses these JPMS-enabled artifacts with popular Reactive Streams projects to make sure there is a clear picture of impacts.

Fixes and closes #531

Build Tooling

As described in the other PR, upgrading Gradle allows for use of Gradle Toolchains and other newer Gradle features. Conveniently, this means the build can safely be run under any JDK which supports all the targets needed by this library, and then lower bytecode levels can be requested for testing.

This PR applies those changes: the base JAR build always happens against JDK 11 regardless of the toolchain used to run Gradle. This "baseline toolchain" can be overridden with, say, ./gradlew -PjavaBaseline=17.

Given this change, I have taken other small liberties to clean up the build. For example, CI just provisions and uses JVM 21, relying on Gradle Toolchains for the rest.

Dependency Security

I've enabled Gradle Dependency Locking and Dependency Verification. This can help align build dependencies and prevent supply chain attacks (or just detect bad downloads of JARs).

I've kept these separate in commit log so they can be removed if the maintainers/authors would prefer not to activate these features. On the other hand, if this is seen as a good thing, I'm also happy to take it further to enable SLSA, Sigstore, and SPDX, which would bring Reactive Streams up to the state of the art in dependency security.

JAR Structure

After applying this PR, the JAR structure for the api artifact is:

Care has been taken not to duplicate classes in the Java 9 class root, and to preserve the FlowAdapters.

JAR manifest:

OSGi manifest (Java 9+):

Changelog

• feat(jpms): add module-info.java to api
• chore: adjust builds where needed to release as MRJAR artifacts
• chore: adjust BND tools to not interfere with MRJAR classes
• chore: upgrade gradle → 8.6
• chore: apply updates to groovy dsl for publishing with gradle v8
• chore: add jdk 21 to ci
• chore: build refactors + cleanup for gradle 8.x
• chore: enable gradle dependency locking
• chore: generate lockfiles
• chore: generate dependency verification metadata
• chore: update ci to run at latest lts

[Sineaggi]

@ktoso @rkuhn Could somebody review this mr?