Restore: skip .NET SDK-style projects during no-op evaluation

[dtivel]

In Visual Studio, because .NET SDK-style projects restores are triggered by project nominations from the project system, there should be no need to perform another restore (even a no-op restore) in most build-triggered restores. By skipping these projects during no-op restore evaluation, no-op restore becomes faster relative to how many .NET SDK-style projects are skipped; so, a solution with no .NET SDK-style projects will realize no benefit while a solution with only .NET SDK-style projects will realize maximum benefit.

As an example, I tested a prototype on the NuGet.Client solution, which at the time had 83 projects (74 .NET SDK-style projects and 9 legacy PackageReference projects). With the solution loaded in Visual Studio and the solution fully restored and built once already, building the up-to-date solution involved a ~2.6 no-op restore. By skipping .NET SDK-style projects during no-op restore evaluation, the no-op restore dropped to ~0.6 seconds. GC heap allocations dropped from ~380 MB to ~88 MB. Total GC pauses dropped by ~1 second.

For this optimization we need to ensure:

• .NET SDK-style projects are only skipped when we know the projects are already up-to-date. If a nomination and no-op restore evaluation occur closely together; the no-op restore evaluation should block or be blocked on completion of all nominations or fallback to a real restore.
• .NET SDK-style projects must not be skipped during clean builds (or rebuilds) or explicit restore requests, only the no-op restores that occur implicitly during many larger user scenarios (e.g.: build, debug, static code analysis, etc.).

CC @aortiz-msft, @anangaur

[nkolev92]

I think the first bullet point is already handled.
Only 1 restore can run at any time in Visual Studio.
Each nomination is guaranteed to end in a restore, and if a nomination comes in while a restore is happening, it will just queue a new restore.

Additionally rebuilds already overwrite-no-op, but I'd honestly argue they shouldn't, see #6987.

Note that by skipping the restore completely you are not checking whether all the assets are still on disk, and that could lead into some trouble.

[nkolev92]

Most of these ideas are covered under what I'm trying to do in #9513.

I'm basically trying to move the no-op check at the solution level. I've seen ~60-80% drops in the slns I have tested as well. Note that in my prototype I'm not quite skipping the SDK based projects, but the effort spent on the them is decreased. That allows us to stay correct.

[nkolev92]

Fixed by #9564.

It's not quite the same, but I believe #9513 and this are incongruent.
Right now, we do a quick check that's low of allocations.

#9564 is a bit more aggressive in which, it will allow us to do a faster no-op for legacy based projects too.