Make Core-SDK download blobs from private location when public location fail

Similarly to what is described in this issue and implemented in this PR, Core-SDK will need a similar work, but for downloading .zip blobs and implemented in MSBuild. The logic, I believe, should be the same: builds will initially lookup the file in the public location and, if the download fail and the build is internal, try download from the private location.

Link to sample failing build: https://dnceng.visualstudio.com/internal/_build/results?buildId=393720&view=logs&j=695ed18d-4f96-5f5b-a547-692c59452cfc&t=581b320b-1054-5daf-6073-fa89a72ce14b&l=63

The build that updated Core-SDK eng\version.props file in the above build’s branch is public and thus published the blob to a public location. However, the current logic in core-sdk is to whenever the current build is an internal one look for the blobs in MSRC only, and thus it doesn’t find the file published to the public location.

The implementation I’m planning is this:

• Augment the DownloadFile task to receive a PrivateUri parameter which should be set only if the build is internal.
• DownloadFile task will only try to download files from PrivateUri if the download using Uri fail with error code in the 400 range.

What do you think? @mmitche @livarcocc @dagood @riarenas @markwilkie

[JohnTortugo]

I think the issue is now clarified - please raise your hand if not 😃. So I’ll move forward with the plan outlined in the issue’s description.

@livarcocc can you take a quick look at the plan and let me know if it makes sense to you?

[riarenas]

I think that’s what @JohnTortugo is currently implementing. But yes, we have to do that now.

The way I understand the state of the world now is:

1. When built from an internal/* branch, Core-SDK will look for all its input blobs in the private location (https://github.com/dotnet/core-sdk/pull/4753). I understood this would be enough, as we wouldn’t try to give public builds for inputs during a servicing release.
2. When building from the internal project, Arcade will try to install the specified additional runtimes by first attempting using the public location, if that doesn’t work, try looking in private storage. (https://github.com/dotnet/arcade/pull/4122)

What this issue asks for, is that we give item 1 in that list the same treatment as item 2, as my understanding regarding how the servicing SDK would be constructed was incorrect, and we will need to implement this in the core-sdk repo.