Unified Build - Full VMR Backflow

[premun]

Context

Currently, the VMR is synchronized based on the dotnet/installer repository mapping its commits 1:1 with dotnet/installer. This will have to change once we switch over to the full code backflow model.

As laid out in the Unified Build design documentation, the planned code flow for .NET 9 will change and the individual repositories will only receive and send updates from/to the VMR and not between each other, so the situation looks like this (see VMR Code and Build Workflow for details):

flowchart TD
    subgraph Traditional[Traditional Flow -- .NET 8 and previous]
        tradEmsdk[emsdk]
        tradRuntime[runtime]
        tradWinforms[winforms]
        tradWPF[wpf]
        tradWindowsDesktop[windows-desktop]
        tradEFCore[efcore]
        tradASPNetCore[aspnetcore]
        tradTemplating[templating]
        tradSDK[sdk]
        tradInstaller[installer]
        tradRoslyn[roslyn]
        tradMSBuild[msbuild]
        tradNuGet[nuget]
        tradFSharp[fsharp]

        tradEmsdk-->|Build Outputs|tradRuntime
        tradRuntime-->|Build Outputs|tradWinforms
        tradRuntime-->|Build Outputs|tradTemplating
        tradRuntime-->|Build Outputs|tradSDK
        tradRuntime-->|Build Outputs|tradASPNetCore
        tradRuntime-->|Build Outputs|tradEFCore
        tradWinforms-->|Build Outputs|tradWPF
        tradWPF-->|Build Outputs|tradWindowsDesktop
        tradWindowsDesktop-->|Build Outputs|tradSDK
        tradEFCore-->|Build Outputs|tradASPNetCore
        tradASPNetCore-->|Build Outputs|tradSDK
        tradTemplating-->|Build Outputs|tradSDK
        tradRoslyn-->|Build Outputs|tradSDK
        tradMSBuild-->|Build Outputs|tradSDK
        tradNuGet-->|Build Outputs|tradSDK
        tradFSharp-->|Build Outputs|tradSDK
        tradSDK-->|Build Outputs|tradInstaller
    end

    subgraph VMR[VMR Flow -- .NET 9+]
        vmrRuntime-->vmrVMR
        vmrWinforms-->vmrVMR
        vmrWPF-->vmrVMR
        vmrWindowsDesktop-->vmrVMR
        vmrEFCore-->vmrVMR
        vmrASPNetCore-->vmrVMR
        vmrTemplating-->vmrVMR
        vmrEmsdk-->vmrVMR
        vmrSDK-->vmrVMR
        vmrInstaller-->vmrVMR
        vmrRoslyn-->vmrVMR
        vmrMSBuild-->vmrVMR
        vmrNuGet-->vmrVMR
        vmrFSharp-->vmrVMR

        vmrEmsdk[emsdk]
        vmrRuntime[runtime]
        vmrWinforms[winforms]
        vmrWPF[wpf]
        vmrWindowsDesktop[windows-desktop]
        vmrEFCore[efcore]
        vmrASPNetCore[aspnetcore]
        vmrTemplating[templating]
        vmrSDK[sdk]
        vmrInstaller[installer]
        vmrRoslyn[roslyn]
        vmrMSBuild[msbuild]
        vmrNuGet[nuget]
        vmrFSharp[fsharp]
        vmrVMR[VMR]

        vmrVMR-->vmrEmsdk
        vmrVMR-->vmrRuntime
        vmrVMR-->vmrWinforms
        vmrVMR-->vmrWPF
        vmrVMR-->vmrWindowsDesktop
        vmrVMR-->vmrEFCore
        vmrVMR-->vmrASPNetCore
        vmrVMR-->vmrTemplating
        vmrVMR-->vmrSDK
        vmrVMR-->vmrInstaller
        vmrVMR-->vmrRoslyn
        vmrVMR-->vmrMSBuild
        vmrVMR-->vmrNuGet
        vmrVMR-->vmrFSharp
    end

    Traditional-->VMR

The updates of the VMR will no longer happen when dotnet/installer is updated but rather whenever a new build appears in one of the channels. The information making the builds of the dev/17.4 branch of dotnet/roslyn end up in the 7.0.3xx SDK band is stored in the configuration of Maestro subscriptions between those branches. The Maestro service will have to follow this configuration and update the corresponding sources (the right folder of the right branch) of the VMR accordingly. It will also have to flow changes the other way too when a change is made in the VMR or when VMR produces a new build output package. This is all new functionality that Maestro will have to implement.

Goal

The goal is to design and implement this dependency flow system. The design should include a rollout plan which will be then executed and product repositories onboarded onto the new dependency flow. Finally, the VMR will be opened for changes.

Technical objectives

• [x] #2714
• [x] #2715
• [ ] Tooling and service infrastructure is created and tested
• [ ] Product repositories are onboarded onto the new flattened dependency flow
• [ ] VMR is opened for changes