Make runfiles incrementally correct with --nobuild_runfile_links

[fmeum]

Fixes three separate but related issues with --nobuild_runfile_links:

• On all OSes, flipping --enable_runfiles from on to off did not result in runfiles being cleared due to a missing call to SymlinkTreeHelper#clearRunfilesDirectory that was only added to SymlinkTreeStrategy in f84329e.
• On Windows only, flipping --enable_runfiles from off to on did not result in runfiles being created since the logic in RunfilesTreeUpdater would see a copy of the manifest instead of a symlink. This is fixed by additionally checking whether the runfiles directory contains the first runfile on Windows. If runfiles were disabled before, it won't, otherwise it will.
• On all OSes, --noenable_runfiles was ignored by bazel run, with runfiles always being created. This is fixed by using RunfilesTreeUpdater instead of custom and incorrect logic.

With the fixed behavior, the runfiles tree for tests is now cleared right before the test spawn is executed, which makes the test action unable to create its working directory, the subdirectory of the runfiles directory corresponding to the workspace name. To fix this and also get rid of the inconsistency of having another action write into the runfiles tree, this logic is moved into the SymlinkTreeHelper and thus applied to all runfiles trees.

Work towards #20676
Fixes #19333

[fmeum]

@tjgq This turned out to be an unexpectedly deep rabbit hole of tangled issues. I added a bunch of new tests and got them to pass, ignoring what I think are flakes. I can definitely try to split this into smaller bits, but some of the fixes cause regressions in isolation.

As I'm ultimately trying to fix #20676 by getting rid of RUNFILES_MANIFEST_ONLY, I'm wondering what you would think of replacing it with a marker runfile (e.g. an empty top-level _runfiles_manifest_only file) created only by SymlinkTreeHelper#clearRunfilesDirectory and used as a signal to use the manifest by runfiles libraries. This could also be a less hacky replacement for the up-to-dateness check in RunfilesTreeUpdater on Windows. I don't remember seeing any breakages when we added _repo_mapping.

[tjgq]

Note: changed RunfilesTree#getWorkspaceName on import to return String instead of PathFragment, as it seems a more natural choice.

[tjgq]

@tjgq This turned out to be an unexpectedly deep rabbit hole of tangled issues. I added a bunch of new tests and got them to pass, ignoring what I think are flakes. I can definitely try to split this into smaller bits, but some of the fixes cause regressions in isolation.

As I'm ultimately trying to fix #20676 by getting rid of RUNFILES_MANIFEST_ONLY, I'm wondering what you would think of replacing it with a marker runfile (e.g. an empty top-level _runfiles_manifest_only file) created only by SymlinkTreeHelper#clearRunfilesDirectory and used as a signal to use the manifest by runfiles libraries. This could also be a less hacky replacement for the up-to-dateness check in RunfilesTreeUpdater on Windows. I don't remember seeing any breakages when we added _repo_mapping.

Sorry, I missed this when reviewing your PR. I think what you describe is quite reasonable. (I'd suggest inverting the meaning of the marker to have it signal that the symlinks have been created; that seems more natural to me, but maybe there are reasons why it has to be the other way round.)

[tjgq]

(Thanks for working on this, though - I set out to fix the incrementality issues with the runfiles flags a while ago, but could never quite find the time/patience to get to the end of it :))