Builds triggered by DevKit features shouldn't restore all the time

Describe the Issue

When I'm tethered on my laptop, or otherwise in degraded network connections, the builds triggered by DevKit to drive experiences like

• Test Explorer refresh
• Test Explorer build-before-test-runt

and more lean on the default behavior of the dotnet CLI, meaning they trigger a Restore. In degraded network conditions this restore is not likely to succeed, and so the entire experience is unusable due to what is seen as a failed build.

In addition, for larger repos Restore contributes significantly to the overall performance of even no-op, inner-loop builds. Here's an obfuscated binlog timeline for an internal partner repo. This repo has ~200 projects in it.

The green portion of this build is the Restore phase. This phase alone accounts for about half of all of the MSBuild Evaluations that occur during the overall build and ~20% of the overall build duration.

In an ideal world, DevKit would not do restores for 'inner-loop' builds and add --no-restore to these builds. DevKit should be aware of actions that do require a restore (modifying packages, manipulating project files, etc) and should handle restores behind the scenes (or allow a user to do an explicit restore).

Steps To Reproduce

1. Clone a dotnet-org repo, e.g. dotnet/msbuild
2. run build.cmd/build.sh
3. disable your network adapter
4. Open VSCode
5. perform a test explorer refresh or a test execution
6. Note that the failing restore blocks the workflow

Expected Behavior

In degraded networking conditions (or optionally in the usual course of test explorer discovery/execution) Restore should not be triggered so builds are more likely to succeed.

Environment Information

• OS: Windows
• VSCode Version: 1.103.0
• DevKit Version: 1.40.30-g4e486a3f24

Start with the DevKit paths used by Test Explorer refresh and test execution, then trace how those actions invoke builds and Restore. The issue provides no file or test entry points; done means inner-loop builds avoid Restore where appropriate while actions that require it still handle restoration.