Use --disable-parallel during xplat restores

[dagood]

Works around NuGet parallel restore timeouts becoming build failures when the machine has a slow connection, for example in our Docker Fedora containers.

See https://github.com/dotnet/core-setup/issues/327

Upgrades buildtools to take dotnet/buildtools#1114

Restore takes a very long time (> 7 minutes) in my Fedora 23 Docker container, but I haven't compared before/after yet. Having 4 NuGet sources seems like it would hurt even more with --disable-parallel. Some followup work to this would be to add a switch to let devs enable parallel restores if their connection can handle it.

I noticed a manually-queued (I think) Fedora build succeeded recently: https://mseng.visualstudio.com/dotnetcore/_build/index?buildId=3380864&_a=summary. Getting a lucky connection speed is a factor in this bug, so it's possible that instead of taking this PR, CLI could start spinning builds repeatedly to get successful ones.

@livarcocc @piotrpMSFT
/cc @dleeapho @mellinoe

[dnfclas]

Hi @dagood, I'm your friendly neighborhood .NET Foundation Pull Request Bot (You can call me DNFBOT). Thanks for your contribution!
You've already signed the contribution license agreement. Thanks!

The agreement was validated by .NET Foundation and real humans are currently evaluating your PR.

TTYL, DNFBOT;

[dagood]

Merged, resolved conflicts, and added --disable-parallel to the tests, as far as I can tell. I got a successful build on my Fedora 23 container. I'll do my before/after measurements on OSX (since a "before" build on Fedora would fail).

[dagood]

My OSX msbuild timings are:

• 00:19:01.12 (with parallel)
• 01:01:12.25 (--disable-parallel)

I believe buildtools setup isn't included in that, which takes up a decent chunk of time in both cases.

Any ideas what the windows errors are? https://ci.dot.net/job/dotnet_cli/job/rel_1.0.0/job/release_windows_nt_x64_prtest/458/

@dotnet-bot test Windows_NT x64 Release Build

[TheRealPiotrP]

@dotnet-bot test Windows_NT x64 Release Build please.

[livarcocc]

@dotnet-bot test Windows_NT x64 Release Build please.

[dagood]

@livarcocc Did you see a build where #4527 didn't make restores work? (@mellinoe suggested merging only the NSS upgrade until it was proven to be not enough.)

[saineshwar]

Still facing same issue after run command :- dotnet restore --disable-parallel

[TheRealPiotrP]

Looks like you're having issues reaching NuGet servers. Can you open this issue in the nuget/home repo, @saineshwar ?

[dagood]

Maybe there's some context I'm missing, but it's possible @saineshwar is using a version of dotnet that doesn't have the parallel HTTP workaround implemented in the NuGet version it uses--and unfortunately there's no way to check without manually comparing the versions or peeking at the IL. (In any case, it's unrelated to this PR, because this PR was only meant to start using --disable-parallel in CLI.)

@saineshwar what version of dotnet are you using? (dotnet --version)

Here's the NuGet issue about parallel restore timeout failures that --disable-parallel is the workaround for: NuGet/Home#2945