The NetCore-Public-XL pool can't handle the volume of PRs in sdk

[ViktorHofer]

We will soon switch the VMR to be produced out of sdk instead of installer. This means that PRs will trigger the sdk-source-build and sdk-unified-build pipelines. Sdk has between 15-20 PR builds on average which means that we trigger 7 * 18 builds in the NetCore-Public-XL pool in average just for the VMR PRs. Rolling builds also queue a significant number of builds.

To handle that volume and avoid timeouts we should consider the following before enabling the pipeline in sdk:

1. Move builds that don't need to use the XL pool off of it. I.e. short stack builds.
2. Batch some of the dependency flow sdk PRs together which should reduce the volume significantly.

I think we need to do both before we can enable the pipelines in sdk.

cc @mmitche @premun @marcpopMSFT @MichaelSimons @MiYanni @ellahathaway

[mmitche]

Before doing 2, let's confirm what the size/cost of this pool is first to make sure the increase in volume won't be a problem overall. 1 is good though, I think.

[MichaelSimons]

Batch some of the dependency flow sdk PRs together which should reduce the volume significantly.

Capturing a side conversation we had on this. The dependency flows we would batch are the ones that are stable and rarely cause any breaks. The contentious flows like runtime, aspnet, roslyn, etc. would remain standalone flows.

Aside from these two, I believe we can justify the ROI here on increasing the pool size.

[ViktorHofer]

Submitted dotnet/sdk#40627 for action item number one.

[ViktorHofer]

We are hitting resources issues already but that might due to me re-spinning a bunch of builds that failed. Let's see how this looks tomorrow.