MSBuild Server - enable for all dotnet CLI-based builds

[JanKrivanek]

Context

MSBuild server is currently opt-in. There might be scenarios where it might bring performance gains. There as well might be possibility to further leverage MSBuild Server (though there is a overlap with current VS build caching techniques). The value and trade-off might not be fully clear

Goal

• Collect feedback from stakeholders (PM/EM), suggest the path forward (if any) and secure stakeholders buy-in for those
• If needed actions are identified - start properly tracking and prioritizing those

Current State

We're concerned about runway for getting MSBuild Server enabled for all SDK users in the 10 GA release. We know of one area of concern (NuGet auth) that we need to do a mitigation around, and are concerned that we don't have enough previews/RCs left to
*

• roll out the change
• get broad user feedback/experience
• react as necessary to that feedback

without either running out of time or negatively impacting the user perception of 10 GA's stability.

Therefore we're going to take the following course of action:

• 10 GA:
  • mitigate the NuGet auth problems by pushing the Restore task out of proc when MSBuild Server is enabled (also helps folks that use server today)
  • get primary dotnet-org repos using Server to kick the tires
• 10.0.200
  • enable server at the SDK level

This mirrors our plan for the multithreaded work, where we're doing enablement/foundational work for 10 GA but not enabling it by default due to time/risk.

[baronfel]

One of the reasons it's off by default is a known issue with the NuGet credential providers used in Restore - which has been fixed as of a couple weeks ago! We should be clear to pick this effort back up now.