Fix symlink creation on older Windows versions

[khogeland]

This patch ensures that the SYMBOLIC_LINK_FLAG_ALLOW_UNPRIVILEGED_CREATE flag is not passed to CreateSymbolicLinkW when the developer mode registry key is not present and enabled on a supported version of Windows. This allows symlinks to be created when Bazel is run with elevated privileges, regardless of Windows version or developer mode.

I also removed the dummy file creation check while refactoring that code for reuse. It seemed overly complicated vs. simply checking the registry and failing during runfiles creation if we're not admin. Please let me know if there's some subtle reason it needed to be done that way.

Fixes #13169 - tested on Windows Server 2016.

[google-cla]

Thanks for your pull request. It looks like this may be your first contribution to a Google open source project (if not, look below for help). Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 Please visit https://cla.developers.google.com/ to sign.

Once you've signed (or fixed any issues), please reply here with @googlebot I signed it! and we'll verify it.

---

What to do if you already signed the CLA

Individual signers

• It's possible we don't have your GitHub username or you're using a different email address on your commit. Check your existing CLA data and verify that your email is set on your git commits.

Corporate signers

• Your company has a Point of Contact who decides which employees are authorized to participate. Ask your POC to be added to the group of authorized contributors. If you don't know who your Point of Contact is, direct the Google project maintainer to go/cla#troubleshoot (Public version).
• The email used to register you as an authorized contributor must be the email used for the Git commit. Check your existing CLA data and verify that your email is set on your git commits.
• The email used to register you as an authorized contributor must also be attached to your GitHub account.

ℹ️ Googlers: Go here for more info.

[meteorcloudy]

Thanks! This indeed looks better than the previous check overall.

But one corner case is that: what if you are on a Windows version prior to Windows 10 Creators Update (1703), and you also have developer enabled. In this case, the implementation in this PR will try to create the symlink with the SYMBOLIC_LINK_FLAG_ALLOW_UNPRIVILEGED_CREATE flag, which the system doesn't support. However it should be able to create the symlink if the user has admin right.

Can you please verify if this is a problem on Windows Server 2016?

[philwo]

I was going to say that Windows 1703 (even Enterprise) is long EOL since 2019, but indeed Windows Server 2016 is still supported until 2022 😳

[khogeland]

Ah, alright, I misinterpreted the Bazel docs and thought those features were introduced at the same time, but that is a possible situation.

[khogeland]

@meteorcloudy I've added an explicit OS version check to make sure Bazel never passes the flag to an incompatible version of Windows.

[meteorcloudy]

Thank you so much! Getting rid of the dummy link approach is really nice!

[meteorcloudy]

@khogeland Can you please sign the CLA so that I can merge this PR? 😃

[khogeland]

@meteorcloudy I see the cla: yes label, is there something else I need to do? I rewrote my initial commit to use the email on our CCLA

[meteorcloudy]

@khogeland Oh, my mistake, everything is good to go!