Normalize Azure devops URIs during asset manifest creation

[riarenas]

• This issue is blocking
  We have at least one instance of build breaks due to discrepancies in the format of the azure URIs: https://dnceng.visualstudio.com/internal/_build/results?buildId=1179028&view=results
• This issue is causing unreasonable pain

At some point it looks like Azure devops decided to change the format of their URIs, as an example, the format of the repository URI build variables changed from: https://dnceng.visualstudio.com/internal/_git/repo-name to https://dnceng@dev.azure.com/dnceng/internal/_git/repo-name

When a build runs some of its legs in machines that have an old enough agent version to use the old URI format, we are hitting errors when publishing to the BAR, because we need all the manifests produced by the legs to have this information in sync.

We should add some normalization logic to the build manifest creation to guard ourselves against these kinds of changes.

[riarenas]

We've only seen this once ever, but it seems like the kind of thing that can bite us unexpectedly if the Azure devops folks decide they want a new format for the URIs again, so I think this should go into FR.

[michellemcdaniel]

Looks like we could just take the NormalizeUrl function from the AzureDevOpsClient in DarcLib and port it to arcade. I assume we don't want any dependencies in arcade on darclib, correct?

[riarenas]

I'm not sure any changes would need to be made in Arcade. The failing task lives in Arcade-services: https://github.com/dotnet/arcade-services/blob/main/src/Maestro/Microsoft.DotNet.Maestro.Tasks/src/PushMetadataToBuildAssetRegistry.cs

[michellemcdaniel]

Oh, I thought the issue was with the actual creation of the individual manifests? Do we not care if they're normalized there?

[riarenas]

I personally don't see a problem with the individual manifests using different versions of the URI as long as the task understands that they are the same. Nothing should be processing them individually anyways. Not sure if there's any pushback in that regard.

If we want to normalize ASAP (when the Build object gets created) then yeah, the code should go into arcade, and it should probably not introduce a dependency on darclib.