There is no need to store relative path today. But some part of the system does not accept relative path and there is no indication if it is storing full path or not. This is the root cause of https://github.com/dotnet/cli/issues/9319
“someplace” means different full path for Path class on unix and Windows. And the mock file system uses real Path class. Change tests' setup to use essentially “TEMPATH/someplace” instead of “someplace”
The `GivenFailedPackageInstallWhenRunWithPackageIdItShouldFail` test should
match against `ToolInstallationFailedWithRestoreGuidance` and not
`ToolInstallationFailed`. This passed prior to the LOC update because
the former started with the latter and a "contains" match was being performed.
If there are shims packaged by convention in nupkg. Shim Repository will simply copy it to the right location.
The query interface ToolPackageInstance will be in charge of finding the shim folder and filter the right RID. Shim Repository will pick the right file after the folder is located since Shim Repository knows the shim name and it also book keep the files at uninstallation.
During development, due to the wrong adapter level. The mock duplicated too much logic. So, I corrected the abstraction level to lower (only create shim). And replaced the existing mock with a much smaller one without any atomic control and file move, copy logic. At the same time. The chmod, which is a IO action, causes problem during tests. So I added adapter layer to it and put it in Util.
