Fix #17501

[vzarytovskii]

The approach I want to take is to cache the results of type subsuming for two given types (in TypeFeasiblySubsumesType & co).

For now just make code a bit more readable, trying to figure out how should we approach the caching itself, since TType itself is not have and equality for it (by design), since we can have non-nominal generic types, where TType_var's solution can be (and is) mutable, and can change with time.

Update, perf:
With cache (PR): 5.8s
Without cache (main): 130.9s
On a real project with issue (OpenTK, which uses NET 8 BCL and its types extensively), compiled successfully.

One concern is that there can be a hash collision eventually, which will trip this logic. But I will play with additional value comparisons if we hit the cache.

[github-actions]

❗ Release notes required

---

✅ Found changes and release notes in following paths:

Change path	Release notes path	Description
src/Compiler	docs/release-notes/.FSharp.Compiler.Service/9.0.200.md
LanguageFeatures.fsi	docs/release-notes/.Language/preview.md

[vzarytovskii]

It helps compilation. By a lot (130s -> 5s).

A bunch of blocking issues I'm not yet sure how to address:

1. If in interactive session, we use shared amap, thus there will potentially be a lot of false-positive cache hits.
2. In tooling scenario, we potentially have a lot of false-positive cache hits:

   type A implements interface IA, we cache it.
   interface IA is removed from the type A, it's still in the cache.
   Any check will pass for "is A an IA".

For 1st, we can technically clean the cache on each FSI submission.

For 2nd - I am not sure what to do, since we fill in the cache on-demand. Pre-filling it will be costly and will slowdown every single compilation and check. Checking interfaces on any cache hit will neglect this optimization.

One of the solutions might be to only enable it for compilation.

[T-Gro]

I added a few remarks for myself as I plan to (later) finish this impl.

[vzarytovskii]

I addressed a couple of them. I still think that it's tested enough (as good as we can), plus is hidden under flags (language and tooling), and think that we can merged it as is, it's better to test it this early than try and plan "better" solution. But then again, if there's any pushback, happy to hear a better plan/solution to it.

[vzarytovskii]

This is ready @dotnet/fsharp-team-msft

[gusty]

It would be interesting to see if there's any perf gain when comparing to .net6/.net7 ?
Or does the optimized code not even exists there?

[vzarytovskii]

It would be interesting to see if there's any perf gain when comparing to .net6/.net7 ?

Or does the optimized code not even exists there?

Will generally be minimal, because bcl there didn't have such large type hierarchies.