chore: Update projects that use Arrow 18 to require Java 11

[niloc132]

These projects depend directly or indirectly on Arrow v18 jars, which are compiled to require Java 11. Gradle correctly fails to build if a project depending on one of these still tries to use Java 8.

Follow-up #6347

[devinrsmith]

I'm surprised that gradle doesn't fail to build these JARS that target --release 8; I would have thought / hoped that was the case? Does it implicitly upgrade them to --release 11 based on their dependencies?

I don't think we need / want to bump java-client-session / java-client-session-dagger to 11 since it should not depend on Arrow.

[niloc132]

I think Gradle can only fail in that way if we could have gotten the org.gradle.jvm.version=11 attribute on the arrow jars - but as they are published by maven, they don't include gradle-specific metadata. I did spend a little time to see if we could annotate our libs.versions.toml or maybe reintroduce a Classpath.groovy or bom project that would add annotations to our dependencies, but didn't find an obvious way. Likewise, javac doesn't seem to care that --release=8 was passed with a classpath that includes Java 11 bytecode - which makes some sense, since that would actually require each JDK is shipped with the full bytecode of all APIs before it, rather than some metadata of what changed.

java-client-session explicitly depends on proto-backplane-grpc, which as of this patch is now Java 11, because in turn it depends on flight. Granted, that is a compileOnly dependency, but we do have classes that use it. If you restore languageLevel=8 to java-client-session, the build will begin to fail since proto-backplane-grpc still is 11 - and in turn if we restore languageLevel=8 to proto-backplane-grpc then while it won't fail, that's only because your above "why doesnt gradle fail with --release 8" doesn't work as we expected - fixing that in our build may yet be possible, and I don't think we should try to make it easier to run Java 8 when we're actively trying to reduce support there.

[devinrsmith]

I would have hoped that the bytecode level of the JAR would be enough information to suss this out; if not via javac, then through gradle :/

Although, I guess technically, I can strongarm an argument for why it is the way it is: "Yes, I'm creating a Jar that only uses Java 8 features, and builds a Java 8 compatible Jar; and even though I depend directly/transitively on Java 11+ Jar, that's a concern for runtime, and shouldn't effect my Jar in isolation".

[devinrsmith]

I think we should file an issue that languageLevel doesn't provide as strong as guarantees as I would have thought / hoped.