Replace node downloader with vcpkg x-download.

[BillyONeal]

Resolves https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1494956.
This will also make artifacts respect asset caching settings if a SHA512 is provided.

• Calls vcpkg x-download and removes all attempts to download from within Node.
• Adds a console parser for curl's output to extract percentages.
• Adds progress tracking to WinHTTP.
• x-download learns a new switch --z-machine-readable-progress, which artifacts reads to power its progress bars.
• Downloader messages were localized.
• WinHTTP efficiency improved slightly by not calling WinHttpQueryDataAvailable.
• WinHTTP backend now correctly checks that the data is actually written to disk rather than assuming that fwrite succeeds.

[autoantwort]

If you only want the progress in percentage you can use --progress-bar.

And

It's a risky business attempting to machine parse output that was never intended for machine consumption as the tools in question don't treat it as contractual. curls progress bars certainly qualify as "never intended for machine consumption" as far as I know.

[BillyONeal]

It's a risky business attempting to machine parse output that was never intended for machine consumption as the tools in question don't treat it as contractual.

I did say that, and I still agree that is true. However, there's a very big difference in effect here. The worst thing that happens if the output changes and we parse the percentage incorrectly is funny ephemeral progress bar output. Nothing gets edited on disk or similar in the previous discussion where we were talking about mutating portfile.cmake.

Would it be better to check for the presence of those first 2 lines that are the 'key'? The specific order is not documented to be contractual but that k/M/G/etc are 1024s is, see https://curl.se/docs/manpage.html

Also asked curl's maintainer here: https://twitter.com/MalwareMinigun/status/1600570213572825090

If you only want the progress in percentage you can use --progress-bar.

It doesn't use --progress-bar explicitly because that is the "friendly human readable" version rather than the consumable by machines version.

curls progress bars certainly qualify as "never intended for machine consumption" as far as I know.

That's exactly why it doesn't use --progress-bar.

[BillyONeal]

Daniel Stenberg clarified that it's at least semi-contractual here: https://twitter.com/bagder/status/1600615752725307400

[BillyONeal]

Thanks again so much @vicroms :)