Tests: Reduce memory use in ComponentTests

[majocha]

ComponentTests allocate a lot, and the Linux CI instance can barely take it:

A lot of fsi sessions are created to run script tests, that's one reason.
We can cache and reuse them, on practical basis, i.e. it's not always possible and some tests must be excluded from it, but most are fine. To exclude any test that is not cooperating, just run it with singleTestBuildAndRunIsolated.

I also added metrics telemetry export in tests. OTEL export is now generally enabled by setting FSHARP_OTEL_EXPORT env var.

Before, after:

I need this to unblock #18499.

[github-actions]

✅ No release notes required

[majocha]

After:
No memory warning.

Good times:

[majocha]

Underlying issue is possibly #15669.

[majocha]

😮‍💨 this is ready.

[edgarfgp]

You are a Legend Sir.

[T-Gro]

Thanks for getting to the bottom of it, this memory hungriness was introduced by me.

I did when migrating "fat" tests which did full fsc.exe compilation and then ran a dotnet program.
Using a shared FSI session for tests that care about execution results saved sometimes 500ms per test just by avoiding the file IO and process overhead - at the cost of keeping stuff in that shared session and increasing memory.

Manually choosing between shared and isolated sounds good.

If we really want to dogfood and automate this "shared vs isolated" decision, we could consider using the new caching+eviction mechanisms to balance amortized startup time overhead vs. memory :)) (in practise it would be hard to predict upfront which tests will consume a lot, the level of variation between test file sizes is quite high)

[majocha]

Yes, getting the tests in-proc (and in memory as opposed to on disk) is generally good. This here is just a workaround and the actual issues are

1. the memory is not reclaimed when one would reasonably expect it to be.
2. what exactly is so costly memory-wise when creating a new fsi session?

[T-Gro]

Yes, getting the tests in-proc (and in memory as opposed to on disk) is generally good. This here is just a workaround and the actual issues are

1. the memory is not reclaimed when one would reasonably expect it to be.
2. what exactly is so costly memory-wise when creating a new fsi session?

One suspect could be loading of all the necessary implicit framework imports and their related objects (Types, Methods,..)