[Bug]: ResultsCache ignores some of the BuildRequest data, may return incorrect results

[ladipro]

Issue Description

ResultsCache ignores BuildRequestDataFlags.ProvideProjectStateAfterBuild and RequestedProjectState, which may lead to incorrect over-sharing and returning incomplete results. BuildResult.ProjectStateAfterBuild is used by design-time builds in Visual Studio where this issue was discovered.

Steps to Reproduce

The repro is provided as a private MSBuildLocator branch: https://github.com/microsoft/MSBuildLocator/compare/master...ladipro:MSBuildLocator:results-cache-bug

Build and run the BuilderApp project to reproduce.

Expected Behavior

Build succeeds.

Actual Behavior

Build fails because the second submission returns null ProjectStateAfterBuild despite having constructed the build request with BuildRequestDataFlags.ProvideProjectStateAfterBuild.

Analysis

The two build requests appear to be treated as identical by the results cache. The cached results of the first build request are returned when the second build request is submitted.

Versions & Configurations

Visual Studio 17.9.34322.171

[YuliiaKovalova]

revert changes due to the detected issue: Bug 1943607 in Azure dev ops

[ladipro]

The changes in #9565 had the side effect of making requests with ProvideSubsetOfStateAfterBuild not cacheable, which broke VS design-time builds. Debugging AB#1943607 has pinpointed this to: https://github.com/dotnet/msbuild/blob/299e0514835a1588e6ef21b1da748462dec706b8/src/Build/BackEnd/Components/Scheduler/Scheduler.cs#L453

Note that if TrySatisfyRequestFromCache fails, we use newResult.Clone() and this instance is not going to have _projectStateAfterBuild set because neither Clone nor BuildResult constructors preserve the field. This may not be the only issue but it's generally what's believed to be happening in the problematic scenarios - the assumption that what we just built is in the cache is broken, and we consequently return incomplete results to VS.