SB prep download of PSB artifacts can't target internal builds

[mthalman]

The changes from dotnet/dotnet#1910 changed how the SB prep script targets the URL to download the PSB artifacts. It always uses the https://ci.dot.net/public/source-build URL which is published to by the VMR build. But this is only true for public branches of the VMR. For internal branches, like would be done for servicing post-GA, it would be publishing to the internal URL at https://ci.dot.net/internal/source-build. So there would be no corresponding bits at https://ci.dot.net/public/source-build for that particular build.

Instead, we would need to rely on the release pipeline to make the artifacts available upon release.

But we can't just revert the changes in dotnet/dotnet#1910 so that it goes back to using the artifacts from the https://builds.dotnet.microsoft.com/source-built-artifacts/assets URL. Because that PR was solving a real problem for non-1xx feature bands. It created alignment with the RIDs between PSB and shared component artifacts. The --target-rid passed to the script applied to both artifact types. Without those changes, you would otherwise need two separate RID arguments to the script to differentiate the behavior for the artifact types: (always set the RID in order to get the right shared component artifacts and optionally set the RID for the PSB artifacts if you don't want CentOS). But that creates a poor UX for the script.

So if we do keep the current RID logic in the script but change what the download URL is, we then need to consider what this means for the release pipeline. If we're saying that PSB artifacts need to be addressed by their specific RID, not just CentOS, then the release pipeline needs to publish the artifacts for all of our RIDs.

And for how to handle the shared component artifacts, I think this could be done with fallback behavior. It would first try to find the artifacts at https://builds.dotnet.microsoft.com/source-built-artifacts/assets (that would satisfy the scenario of the publicly released versions). If it doesn't find it there, it would fall back to https://ci.dot.net/public/source-build (that would satisfy the scenario of daily builds between releases).