Do not create runfile trees unnecessarily when building without the bytes

[tjgq]

Currently, --remote_download_toplevel causes all runfiles symlink trees to be created (not just the top-level ones), while --remote_download_minimal implies --nobuild_runfile_symlinks and activates a separate code path (see RunfilesTreeUpdater) to create input runfiles trees just before local action execution.

Instead, we should:

1. Return true from RemoteOutputService#canCreateSymlinks and provide an empty RemoteOutputService#createSymlinks implementation; this ensures the runfiles tree is never materialized as a direct result of running the SymlinkTreeAction.
2. Have SpawnRunner#prefetchInputs create the runfiles tree before local action execution (as is already the case for other local action inputs).
3. Have AbstractActionInputPrefetcher#finalizeAction create the runfiles tree for toplevel targets (as is already the case for other top-level outputs).

This would ensure a minimal set of runfile trees is created in all cases, and let us omit --nobuild_runfile_links from the expansion of --remote_download_minimal.

[tjgq]

After spending a lot of time investigating this, I don't see a way to fix this issue that doesn't result in an uncomfortable amount of complexity to be added. The "build without the bytes" machinery only really works for remote actions, but runfiles are an internal (in-process) action, and tracking an "executed-but-not-yet-materialized" state for such an action is not a simple change. It would potentially be worth doing if extended to other in-process actions (FileWriteAction, TemplateExpand, etc) but I don't see evidence that this is necessary, and I'd prefer not to introduce it just for the sake of runfiles.

Instead, I think for now we should simply remove --nobuild_runfile_links from the expansion of --remote_download_minimal and move on. This is technically a regression, but:

• Users can still manually set --nobuild_runfile_links if they care.
• As a benefit, we no longer discard the entire analysis phase when switching between --remote_download_minimal and --remote_download_toplevel, or between a local and remote build, on account of --nobuild_runfile_links changing.
• In the future, we should consider defaulting --build_runfile_links to false; runfile symlink trees are unlikely to be interesting output artifacts except for debugging purposes, and are best regarded strictly as a property of the action execution environment.

I acknowledge that this leaves us without a mechanism to selectively decide which targets to materialize runfile symlink trees for, but again, I'd like to see evidence that this is necessary. (Note that it will remain the case that runfile symlink trees are created just-in-time whenever required by a local action or a bazel run command.)