Split `Versions.props` into two files: one for humans, and one for Maestro/Darc

[dkurepa]

Context

Currently, Versions.props is a problematic file for the codeflow algorithm.
This is because it contains manually added properties by developers, but it's also regularly changed by automation.
The current three way merge algorithm we have in place #4342 can't backflow manual changes to non dependency properties, meaning that any change to properties like PreReleaseVersionLabel gets lost.

To solve this issue, we want to split this file into two:

• one for developers
• one for automation

This should help solve the issue above

Goal

Split Version.props into two files. Perhaps do this using Maestro subscriptions: make it so when Maestro is updating repo with new dependencies, it looks them up in Version.props, removes them and adds them in the new file.

Also note that we will need a change in arcade too, one that makes it so the properties in the new file get added to the build. We should do these changes before we make them in Maestro

[dkurepa]

After talking with Matt and Premek, we concluded the following:

• We'd create support for a separate props file called Version.Details.props which would be generated every flow based on the Version.Details.xml (we already have a tool that can do this https://github.com/dotnet/arcade-services/tree/main/tools/VersionPropsFormatter)
• Repos would be able to opt into having this file by creating it manually, after which Maestro would populate it during its operations
• Version.props would import the new Version.Details.props so it can reference dependency versions, this also means we wouldn't have to make any arcade changes
• We'd have checks making sure these files are ok (checking that the properties don't overlap, etc..)

[dkurepa]

I've opened up a PR #5067 for this issue.
The PR makes it so Maestro checks if the Version.Details.props file exists, and if it does, it regenerates it after update Version.Details with new versions. It supports both codeflow and dependency subscriptions.
I also added a merge policy that:

• Check if Version.Details.props exists in the target repo
• If it does, it check if any policies from the file exist in Versions.props
• And checks if Version.props imports Version.Details.props

This won't run on forward flow PRs yet

[dkurepa]

So I think after merging this PR, we can go through all VMR repos, add Version.Details.props and forward flow. On the next backflow, the file should get populated.

After this is done, we should be able to remove Versions.props from the patch exclusion filter, meaning that manual changes made to it in the VMR will backflow (they don't currently)

cc @mmitche

[dkurepa]

Once #5067 is rolled out, we should go to all codeflow repos and create the Version.Details.props file:

• arcade
• aspnetcore
• cecil
• command-line-api
• deployment-tools
• diagnostics
• efcore
• emsdk
• fsharp
• msbuild
• nuget-client
• razor
• roslyn-analyzers
• roslyn
• runtime
• scenario-tests
• sdk
• source-build-reference-packages
• sourcelink
• symreader
• templating
• vstest
• windowsdesktop
• winforms
• wpf
• xdt