Don't reference an action filesystem from build events

[fmeum]

Description

A build event outlives the action or target it refers to: it is uploaded asynchronously, so anything it references stays on the heap until the last transport has delivered it. Several events referenced an action filesystem, which in turn retains everything needed to serve that action's inputs. This removes those references and then makes the property self-enforcing.

Four commits, each reviewable on its own:

1. Test build events. TestAttempt reported test outputs on the test action's RemoteActionFileSystem, retaining the metadata of every input of the test action — for a test, its whole runfiles tree. TestRunnerAction is shared with Blaze and keeps resolving declared outputs through the path resolver, since an action filesystem may be the only place they exist; the conversion to local paths happens in StandaloneTestStrategy, which is Bazel-only and which both paths funnel through — processTestAttempt for an executed test, and newCachedTestResult, which TestRunnerAction#actionCacheHit calls through TestActionContext. Coverage data is always downloaded, but the test log is not under --remote_download_minimal, so TestAttempt also carries its metadata; the uploader prefers that over reading the file and reports a remote-only log as a bytestream URI. This resolves TODO(b/199940216) for the one file that needed it.

2. Completion events. CompletionContext asked the OutputService for a path resolver purely so TargetCompleteEvent and NamedArtifactGroup could turn artifacts into Paths, and RemoteOutputService answered with a RemoteActionFileSystem over the target's ActionInputMap. All six call sites already have the artifact's FileArtifactValue, which the uploader prefers, so Bazel now falls back to ArtifactPathResolver.IDENTITY. NamedArtifactGroup additionally drops its CompletionContext field — it stores eagerly expanded (artifact, metadata) pairs and used the context for nothing else, and there is one such event per nested set node of every target's output groups.

3. ActionExecutedEvent. The primary output and stdout/stderr paths came from the action's path resolver. Reporting stdout/stderr locally also stops the action result upload from reading the action filesystem on a background thread under --remote_cache_async.

4. Enforcement. ByteStreamBuildEventArtifactUploader is Bazel-only, and Bazel's action filesystem is always RemoteActionFileSystem, so it checks every path it is handed and reports a non-fatal bug otherwise — no opt-in mechanism needed, and nothing in a shared class. With the invariant established, the uploader no longer has to ask an action filesystem whether a file is stored remotely: an event that references such a file supplies its metadata, which already says so. isRemoteFile goes away with it.

On other OutputService implementations

The OutputService path resolver hook is deliberately not removed, and commit 3 is conditional on ActionFileSystemType#supportsLocalActions. An action filesystem that takes full control of the output base is the only place its outputs exist, and ExecutionTool does not even create a local action log directory for it, so its stdout/stderr cannot be reported locally. The enforcement in commit 4 lives in the Bazel-only ByteStream uploader, so it does not constrain other implementations at all.

Validation

The invariant check in commit 4 was run across remote/..., buildtool/..., runtime/..., analysis/..., exec/..., skyframe/... and actions/... — 320 tests, all passing, with no production code path tripping it. The single initial violation was ByteStreamBuildEventArtifactUploaderTest#remoteFileShouldNotBeUploaded_actionFs, which handed the uploader an action filesystem path directly; it now expresses remoteness through metadata, the way production does.

Commit 1 has a regression test in StandaloneTestStrategyTest: it feeds newCachedTestResult a test log on a stand-in action filesystem and asserts the resulting TestAttempt reports the same path on the real one.

Note that TrimTestConfigurationTest#flagOffDifferentTestOptions_ResultsInDifferentCTs is flaky independently of this change — it fails roughly 3 in 10 runs on unmodified master.

Motivation

Progress towards #24527. Supersedes #30691 (commit 2 here) and the closed #30692.

Build API Changes

No

Checklist

• I have added tests for the new use cases (if any).
• I have updated the documentation (if applicable).

Release Notes

RELNOTES: None