Allow the creation of relative symlinks on Windows

[fmeum]

Fixes #14224

RELNOTES: Symlinks created via ctx.actions.symlink(..., target_path = "...") with --windows_enable_symlinks can now be relative on Windows.

[tomdegoede]

Thanks for working on this!

I recently observed some weird behavior with relative symlinks created in pwsh.exe on windows. It went something like this:
a/b/c/external/file.x
a/b/c/out/x64/bin/link.x -> ../../../external/file.x
a/b/c/bin -> out/x64/bin
get-content bin/link.x : Error: a/external/file.x does not exist. (Ignoring the fact that link.x lives inside it symlink itself)

I'm not sure if this also works like this on linux and under which specific circumstances this occurs. Maybe the symlinks were made absolute for this reason. We have changed our PowerShell script to produce absolute symlinks (and disabled caching) to fix bazel-bin invocations.

[fmeum]

@meteorcloudy Do you happen to know what's up with relative symlinks on Windows? I can add more test cases.

[meteorcloudy]

I recently observed some weird behavior with relative symlinks created in pwsh.exe on windows. It went something like this:
a/b/c/external/file.x
a/b/c/out/x64/bin/link.x -> ../../../external/file.x
a/b/c/bin -> out/x64/bin
get-content bin/link.x : Error: a/external/file.x does not exist. (Ignoring the fact that link.x lives inside it symlink itself)

This is probably due to

bazel/src/main/java/com/google/devtools/build/lib/bazel/BazelRepositoryModule.java

Lines 516 to 526 in 7ee3e9c

	if (OS.getCurrent() == OS.WINDOWS) {
	// On Windows, symlinks are resolved differently.
	// Given <external>/repo_foo/link,
	// where <external>/repo_foo points to <vendor dir>/repo_foo in vendor mode
	// and repo_foo/link points to a relative path ../bazel-external/repo_bar/data.
	// Windows won't resolve `repo_foo` before resolving `link`, which causes
	// <external>/repo_foo/link to be resolved to <external>/bazel-external/repo_bar/data
	// To work around this, we create a symlink <external>/bazel-external -> <external>.
	FileSystemUtils.ensureSymbolicLink(
	externalRoot.getChild(VendorManager.EXTERNAL_ROOT_SYMLINK_NAME), externalRoot);
	}

So given:

pcloudy@bazel-windows-playground:~/workdir/symlink_test
$ tree .
.
├── external
│   ├── bar -> /c/Users/pcloudy/workdir/symlink_test/vendor/bar
│   └── foo -> /c/Users/pcloudy/workdir/symlink_test/vendor/foo
└── vendor
    ├── bar
    │   └── file
    ├── external -> /c/Users/pcloudy/workdir/symlink_test/external
    └── foo
        └── link -> ../external/bar/file

We got different results based on which style of file path you use for cat (probably affects how symlinks in the path was resolved?).

pcloudy@bazel-windows-playground:~/workdir/symlink_test
$ cat c:/Users/pcloudy/workdir/symlink_test/external/foo/link
cat: 'c:/Users/pcloudy/workdir/symlink_test/external/foo/link': No such file or directory
pcloudy@bazel-windows-playground:~/workdir/symlink_test
$ cat /c/Users/pcloudy/workdir/symlink_test/external/foo/link
hi

So basically c:/Users/pcloudy/workdir/symlink_test/external/foo/link is resolved to

=> c:/Users/pcloudy/workdir/symlink_test/external/foo/../external/bar/file
=> c:/Users/pcloudy/workdir/symlink_test/external/external/bar/file ❌

but /c/Users/pcloudy/workdir/symlink_test/external/foo/link is resolved to

=> /c/Users/pcloudy/workdir/symlink_test/vendor/foo/link
=> /c/Users/pcloudy/workdir/symlink_test/vendor/foo/../external/bar/file
=> /c/Users/pcloudy/workdir/symlink_test/vendor/external/bar/file
=> /c/Users/pcloudy/workdir/symlink_test/external/bar/file
=> /c/Users/pcloudy/workdir/symlink_test/vendor/bar/file ✅

I think we might want to be a bit careful on opening up relative symlinks on Windows since they behave different due to this issue.