Tool no-op with floating versions issues

[nkolev92]

This is just a tracking task. This is the expected behavior and currently there's no ideas for actually solving this issue. Finding a proper solution would require a complete redesign of tool restore.

The design for tools has a lot of holes itself, as we bind it to a project, but it's actually global etc.
Due to that there's a great amount of cases where tool restore will not work.

The simple scenario here if we have 2 different version declarations that resolve to the same version.

  <ItemGroup>
    <DotNetCliToolReference Include="dotnet-api-search" Version="0.9.5" />
  </ItemGroup>

and

  <ItemGroup>
    <DotNetCliToolReference Include="dotnet-api-search" Version="1.0.0" />
  </ItemGroup>

Both these tools restores would resolve to 1.0.0 and both would end up writing to the same cache file.
In this case we're left at the mercy of the scheduler. Pigeonhole says only 1 restore can no-op, but since these tasks run asynchronously, it may happen that the cache file by the one that CAN no-op has been overriden by another one before we read the cache file.
Due to multiple threads trying to access the lock/cache files, there's many inconsistencies in the tool no-op.
All the known issues with tool no-op are related to the fact that multiple restores compete for the same assets/cache files.

//cc
@emgarten

[nkolev92]

This is just a bad design, and we will not invest much time here.

Closing as won't fix.