[9.3.0] Don't report cancelled remote transfers as errors (https://github.com/bazelbuild/bazel/pull/30652) (#30751)

### Description

When a bulk transfer to or from the remote cache is cancelled, every one
of its in-flight transfers fails with a `CancellationException`.
`mergeBulkTransfer` subscribes to all transfers of a bulk operation at
once via `flatMapSingle`, which terminates on the first error and hands
every subsequent one to RxJava's global error handler.

`RemoteModule` installs a global error handler that reports those as
error events, so a single cancelled bulk transfer printed a
`java.util.concurrent.CancellationException: Task was cancelled` stack
trace for every transfer but the first.

A transfer is only ever cancelled as part of tearing down the operation
it belongs to, so `toTransferResult` now maps `CancellationException` to
the same result as `InterruptedException` instead of propagating it
downstream.

This PR also replaces two `isDisposed()`-then-`onError()` sequences in
`RxFutures` and `AsyncTaskCache` with `tryOnError`. Those checks aren't
atomic with the delivery: the emitter can be disposed in between, in
which case `onError` hands the error to the global error handler as
well.

### Motivation

Users see spurious `ERROR: java.util.concurrent.CancellationException:
Task was cancelled` stack traces, one per concurrently cancelled
transfer, whenever a build that is uploading or downloading blobs is
interrupted or an action fails while a bulk transfer is in flight.

This also shows up as a flake in
`RemoteExecutionServiceTest.uploadInputsIfNotPresent_interrupted_requestCancelled`,
which fails whenever `RxNoGlobalErrorsRule` observes the leaked
exception. That test failed in roughly 2-5% of runs before this change
and passed 100 out of 100 times after it.

### Build API Changes

No

### Checklist

- [x] I have added tests for the new use cases (if any).
- [ ] I have updated the documentation (if applicable).

The existing `uploadInputsIfNotPresent_interrupted_requestCancelled`
covers this, but only probabilistically: the number of transfers that
are cancelled concurrently determines whether an error is leaked, and
the `tryOnError` changes fix races that can't be triggered
deterministically.

### Release Notes

RELNOTES: None

Closes #30652.

PiperOrigin-RevId: 965871323
Change-Id: I14b9109bb2e84544cb0a9d573604c8dd891ecce4

Commit
https://github.com/bazelbuild/bazel/commit/cec8ee49f731e48b5bb336a27a7f2f1be770da48

Co-authored-by: Fabian Meumertzheim <fabian@meumertzhe.im>