Reducing CI runs

[T-Gro]

1. Compressing metadata is stable. Reduce the matrix for test runs to ONLY use the compressed version, and do not do the same on the regular one
2. The same can be applied for trimming, again only trim the compressed metadata version
3. FSharpSuite tests are the dominating part of the longest CI run. Since the total wait time scales with the longest job, it makes sense to optimize here
   • This suite will be invocated separately as a background process, while other tests run

FIY, this is timing of the different test suites used in the longest CI job:

Suite	Timing
Fsharp.Core.UnitTests	Time Elapsed 00:03:48.30
FsharpSuite.Tests	Time Elapsed 00:52:02.98
Fsharp.Compiler.ComponentTests	Time Elapsed 00:07:31.74
Fsharp.Compiler.UnitTests	Time Elapsed 00:00:19.16
Fsharp.Compiler.Service.Tests	Time Elapsed 00:01:11.56
Fsharp.Compiler.Private.Scripting.UnitTests	Time Elapsed 00:01:20.15
Fsharp.Build.UnitTests	Time Elapsed 00:00:04.33

Proof for starting FsharpSuite.Tests on the background:
https://dev.azure.com/dnceng-public/public/_build/results?buildId=129075&view=logs&j=09cc464c-89cd-5758-006d-ba9e3958cfa9&t=098678ff-b2f3-5c88-44d3-4c7be2f47e75&l=2813

(FsharpSuite.Tests is started as a spinoff, then all the smaller/faster test suites happen sequentially, then it waits for FsharpSuite.Tests to finish)

[vzarytovskii]

I'd leave trimming tests intact for now. We're mostly testing that trimmer/linker can process both and not regressed.

[T-Gro]

I'd leave trimming tests intact for now. We're mostly testing that trimmer/linker can process both and not regressed.

It's still running, just only with the compressed version.
The compression is about binary resources...

[vzarytovskii]

I'd leave trimming tests intact for now. We're mostly testing that trimmer/linker can process both and not regressed.

It's still running, just only with the compressed version.
The compression is about binary resources...

No, what I meant is that we should leave both of them running.

We want to make sure uncompressed metadata is trimmed correctly too, since it's to stay in some libraries for a long time.

For example, FSharp.Core shipped uncompressed, and will be uncompressed for some time.

[KevinRansom]

Compilers supporting compression have been available since early november. dotnet sdk 7.0.0. VS 17.4.0.
I think I want to turn it on compression by default for FSharp.Core in VS 17.6.0. In the mean time, I'm okay with running the tests with compressed FSharp.Core and Uncompressed FSharp.Core. If we are getting pressed because ci takes too many resources, then we can remove the tests with Compressed FSharp.Core rather than uncompressed, because Compressed FSharp.Core isn't a customer scenario yet.

[T-Gro]

Compilers supporting compression have been available since early november. dotnet sdk 7.0.0. VS 17.4.0. I think I want to turn it on compression by default for FSharp.Core in VS 17.6.0. In the mean time, I'm okay with running the tests with compressed FSharp.Core and Uncompressed FSharp.Core. If we are getting pressed because ci takes too many resources, then we can remove the tests with Compressed FSharp.Core rather than uncompressed, because Compressed FSharp.Core isn't a customer scenario yet.

Ok, trimming test stays in doubled mode then, change already done.