Ignore run-make tests that use symlink on Windows and adjust symlink wrapper

[jieyouxu]

Noticed in #125674 (comment).

Symlink creation is a privileged operation (std::os::windows::fs::symlink_file), it may be enabled on CI, but it's typically not enabled on user machines.

This PR does two things:

1. We change the support library's symlink wrapper to panic on Windows because user machines typically don't enable priviledged symlink operations. This can manifest in the test passing in CI but failing on a local machine, as is observed in the linked PR comment.
2. We update the tests {symlinked-extern, symlinked-rlib, symlinked-libraries} to //@ ignore-windows since they rely on symlink functionality (they were //@ ignore-windows originally).

cc @petrochenkov since you ran into the failing tests.

[rustbot]

r? @Mark-Simulacrum

rustbot has assigned @Mark-Simulacrum.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[ChrisDenton]

We should ideally still be running these tests in CI. I'm somewhat uncomfortable with outright ignoring them on Windows. In the standard library we use the CI environment variable to know if a test can be allowed to fail. I'm not sure if a similar thing could be done in run-make tests.

Also many developers do enable developer mode on their computer, so it'd be good if the tests did run locally in that situation. But I think that's a less pressing issue.

[jieyouxu]

I'm not sure if a similar thing could be done in run-make tests.

I suppose we could add a directive //@ only-ci, which is... lol.

Also many developers do enable developer mode on their computer, so it'd be good if the tests did run locally in that situation.

I'm not 100% sure on how to handle this, as in try to do a (maybe cached) symlink creation permission test (maybe in compiletest?)? Or something like (this isn't pretty, just illustrative) in the support library

static HAS_WINDOWS_SYMLINK_PERMS: OnceLock<bool> = OnceLock::new();

fn symlink_wrapper(...) -> ... {
	let has_symlink_perms = HAS_WINDOWS_SYMLINK_PERMS.get_or_init(|| {
        let res = /* try do symlink */;
        let can_symlink = res.is_ok();
        /* remove the symlink */
        can_symlink
	});
    /* do the symlink */
}

(It's a heuristic and not robust to TOCTOU problems, but yes)

[workingjubilee]

clearly we should add

//@ needs-symlinks

[petrochenkov]

@jieyouxu
got_symlink_permission in std tests doesn't even try to cache, just tries to make some symlink every time.

[ChrisDenton]

clearly we should add

//@ needs-symlinks

That seems like it would be easy to do? Easy to cache even, The downside is that there's no enforcement. E.g. in CI there's no difference between using needs-symlinks or not.

[petrochenkov]

E.g. in CI there's no difference between using needs-symlinks or not.

Not necessarily, e.g. needs-llvm-components allows to ignore tests locally, but still requires all the components to be present on CI.

[Mark-Simulacrum]

r? @ChrisDenton (but seems right to me in direction + needs-symlink as the path)

[jieyouxu]

Closing this PR for #126862 which implements the cleaner needs-symlinks approach.