Make it possible to actually use (e.g.) -Dsurefire.toolchain.version=21 to set the Java version for tests, and do so in CI. (The property value still _defaults_ to the JDK that you use to run Maven, so passing the flag is not _necessary_.)

[copybara-service]

Make it possible to actually use (e.g.) -Dsurefire.toolchain.version=21 to set the Java version for tests, and do so in CI. (The property value still defaults to the JDK that you use to run Maven, so passing the flag is not necessary.)

This lets us use whatever Java version we want[1] for executing Maven itself—and thus for executing any plugins that aren't toolchain-aware. (I even hacked up our toolchain configuration to run tests under Java 24, and it worked.) I've changed our CI to do that, too, by always using Java 23. (This makes the explicit choice of Java 23 for javac redundant under CI, as well as on our Google workstations. However, it can be useful for anyone who builds Guava locally while having an older JDK as the default version.)

Notably, that means that we can use a new version (like Java 23) for running the GWT plugin, which lets us upgrade to GWT 2.12.1 (cl/711417161), which uses an Eclipse compiler with bytecode version 55 (Java 11)[2]. (This means that users who build guava-gwt locally with Java 8 will need to upgrade their build JDK to at least Java 11—or skip building guava-gwt if they don't need it.)

That GWT upgrade is in turn necessary in order for us to be able to use use JSpecify annotations from our GWT artifact.

In theory, this could also prepare us for further changes, like more easily running tests under multiple versions during our release process (in addition to how we already do so for CI), though there are already other ways of doing that by hacking up our release script or pom.xml. And I'm not sure that I'd really want to do that, anyway. (See also some notes that I've added to cl/639128020.)

I also did some related cleanup:

• Our --no-module-directories configuration probably became Just Wrong back in cl/655647768: It should be based on the version that we use to build Javadoc (which is currently always 11), not the version that Maven is running under. It probably mostly doesn't matter because we probably mostly don't try to run Javadoc under other versions, but I'd like to be able to do so, so this is a step forward.
• -Djava.security.manager=allow is not necessary now that we've cleaned up our usages of SecurityManager. (And that's fortunate, as it seems difficult to active a profile based on a range of values of an arbitrary "my test JRE version" property, as opposed to activate it based on the JDK that Maven is running under.)

Fixes #7492 (by making setup-java download all the toolchains that we need)

[1] I mean, I suspect that Maven support lags new JDKs somewhat, and I've seen problems with other versions (as documented in cl/488902996). But at least we don't have to use the same Java version for executing Maven itself as we do for executing tests.

[2] That was causing this error:

[INFO] --- gwt:2.10.0:compile (gwt-compile) @ guava-gwt ---
Error: [ERROR] Unexpected internal compiler error
[INFO] java.lang.UnsupportedClassVersionError: org/eclipse/jdt/internal/compiler/classfmt/ClassFormatException has been compiled by a more recent version of the Java Runtime (class file version 55.0), this version of the Java Runtime only recognizes class file versions up to 52.0
[INFO] 	at java.lang.ClassLoader.defineClass1(Native Method)
[INFO] 	at java.lang.ClassLoader.defineClass(ClassLoader.java:757)
[INFO] 	at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
[INFO] 	at java.net.URLClassLoader.defineClass(URLClassLoader.java:473)
[INFO] 	at java.net.URLClassLoader.access$100(URLClassLoader.java:74)
[INFO] 	at java.net.URLClassLoader$1.run(URLClassLoader.java:369)
[INFO] 	at java.net.URLClassLoader$1.run(URLClassLoader.java:363)
[INFO] 	at java.security.AccessController.doPrivileged(Native Method)
[INFO] 	at java.net.URLClassLoader.findClass(URLClassLoader.java:362)
[INFO] 	at java.lang.ClassLoader.loadClass(ClassLoader.java:419)
[INFO] 	at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:352)
[INFO] 	at java.lang.ClassLoader.loadClass(ClassLoader.java:352)
[INFO] 	at com.google.gwt.dev.javac.CompilationStateBuilder.doBuildFrom(CompilationStateBuilder.java:488)
[INFO] 	at com.google.gwt.dev.javac.CompilationStateBuilder.buildFrom(CompilationStateBuilder.java:464)
[INFO] 	at com.google.gwt.dev.cfg.ModuleDef.getCompilationState(ModuleDef.java:426)
[INFO] 	at com.google.gwt.dev.Precompile.validate(Precompile.java:145)
[INFO] 	at com.google.gwt.dev.Compiler.compile(Compiler.java:184)
[INFO] 	at com.google.gwt.dev.Compiler.compile(Compiler.java:143)
[INFO] 	at com.google.gwt.dev.Compiler.compile(Compiler.java:132)
[INFO] 	at com.google.gwt.dev.Compiler$1.run(Compiler.java:110)
[INFO] 	at com.google.gwt.dev.CompileTaskRunner.doRun(CompileTaskRunner.java:55)
[INFO] 	at com.google.gwt.dev.CompileTaskRunner.runWithAppropriateLogger(CompileTaskRunner.java:50)
[INFO] 	at com.google.gwt.dev.Compiler.main(Compiler.java:113)

RELNOTES=n/a