[9.0.0] Accept remote execution protocol versions up to v2.11 (bazelbuild#27629)

The latest version of the remote execution protocol is v2.11
(2024-10-16). Meanwhile Bazel always tries to negotiate a version
between v2.0 (2019-11-04) and v2.2 (2020-10-17).

Between remote execution protocol v2.2 and v2.11 there has only been one
backward incompatible change. Namely, v2.2 required that if
Command.arguments[0] was not an absolute path, workers had to assume it
was a path relative to the input root, and no $PATH resolution was
performed. In v2.3 this was changed to be relative to the working
directory, while adding $PATH resolution. It should be noted that this
was specifically changed to improve compatibility with Bazel's local
execution, which always worked like that.

Bazel already implements many features that are only available in
protocol versions newer than v2.2. For example:

- All requests generated by Bazel set digest_function, which was only
added to v2.5.

- Bazel supports BLAKE3 as a hash function, which was added to v2.8.

As I cannot think of any reason why Bazel wouldn't work when run against
a server that only implements the very latest version of the protocol,
let's go ahead and support it.

This change fixes a warning that is generated by Bazel when performing a
build against the very latest version of Buildbarn:

WARNING: The highest API version Bazel support 2.2 is deprecated by the
server. Please upgrade to server's recommended version: 2.3 to 2.11.

On the Buildbarn side we announce a low_api_version of v2.3, as this is
arguably the correct thing to do. Namely, Buildbarn workers always
interpret Command.arguments[0] in accordance v2.3+, meaning that
announcing low_api_version any lower than that is incorrect.

On 2026-04-01 I am also planning on bumping Buildbarn's
deprecated_api_version from v2.0 to v2.2, as I am planning on removing
the following features:

- Platform properties stored in Command instead of Action (REv2.0 ->
REv2.1).
- Output paths listed in Command.output_{files,directories} instead of
Command.output_paths (REv2.1 -> REv2.2).

Ideally I would have gone ahead and bumped the deprecated_api_version to
v2.3, but that would break compatibility with versions of Bazel that do
not include this change.

Closes bazelbuild#27493.

PiperOrigin-RevId: 829097224
Change-Id: I1174d6281f0c44a5e229852bebe4b6451f567195

Commit
bazelbuild@83bd0ce

Co-authored-by: Ed Schouten <eschouten@apple.com>

Author: iancha1992

src/main/java/com/google/devtools/build/lib/remote/ApiVersion.java

@@ -31,13 +31,13 @@ public class ApiVersion implements Comparable<ApiVersion> {
   public static final ApiVersion twoPointOne =
       new ApiVersion(SemVer.newBuilder().setMajor(2).setMinor(1).build());
   // The latest version of the Remote Execution API that Bazel is compatible with.
-  public static final ApiVersion twoPointTwo =
-      new ApiVersion(SemVer.newBuilder().setMajor(2).setMinor(2).build());
+  public static final ApiVersion twoPointEleven =
+      new ApiVersion(SemVer.newBuilder().setMajor(2).setMinor(11).build());
 
   // The current lowest/highest versions (inclusive) of the Remote Execution API that Bazel
   // supports. These fields will need to be updated together with all version changes.
   public static final ApiVersion low = twoPointZero;
-  public static final ApiVersion high = twoPointTwo;
+  public static final ApiVersion high = twoPointEleven;
 
   public ApiVersion(int major, int minor, int patch, String prerelease) {
     this.major = major;