Resumable cancellable with trampolined binds

[majocha]

Description

Just to see if it works at all. Don't worry about it.

This is revived #18285 with cancellable CE reimplemented using resumable code.
Binds are trampolined so if things do work, deep recursion should not be a problem regardless of tailcalls.

The complexity probably makes it not worth it to reimplement just the cancellable, but it could be a starting point to replace internally all the asyncs (and cancellables) in FCS with a compatible and more effective resumable async2 implementation.

[github-actions]

❗ Release notes required

@majocha,

Caution

No release notes found for the changed paths (see table below).

Please make sure to add an entry with an informative description of the change as well as link to this pull request, issue and language suggestion if applicable. Release notes for this repository are based on Keep A Changelog format.

The following format is recommended for this repository:

* <Informative description>. ([PR #XXXXX](https://github.com/dotnet/fsharp/pull/XXXXX))

See examples in the files, listed in the table below or in th full documentation at https://fsharp.github.io/fsharp-compiler-docs/release-notes/About.html.

If you believe that release notes are not necessary for this PR, please add NO_RELEASE_NOTES label to the pull request.

You can open this PR in browser to add release notes: open in github.dev

Change path	Release notes path	Description
src/Compiler	docs/release-notes/.FSharp.Compiler.Service/10.0.100.md	No release notes found or release notes format is not correct

[majocha]

This is failing to compile statically, which is another problem.

[T-Gro]

(side thought - if we had a compiler-only usage of an async variant, we could use it to dogfood under flags when we decide to use runtime's async implementation. The compiler could also provide testing of deeply recursive scenarios there - might be valuable even for the runtime impl itself. But obviously we would have to accept the change of semantics, which will not work for the general library usage of async)

[majocha]

This is currently driven be an explicit synchronous loop.

Another approach would be to use something similar to CancellableTask. That would mean a (mostly) synchronous execution driven by AsyncMethodBuilder, with occasional yields in Bind to allow unlimited recursion without stack overflow.

The problem would be with propagating exceptions (including cancellation) from deep call chains. It could get very expensive, because of async stack trace stitching, see (TheAngryByrd/IcedTasks#3 (comment)).

As a side note, current async implementation has very fast zero-cost cancellation, unlimited recursion and while stack traces are problematic, throwing from deeply nested code is not. This is something valuable to preserve in a potential resumable async2.

[majocha]

As a side note, this gets rid of GuardCancellable, but I've been also thinking about StackGuard.Guard performance in IDE use.
Even when just browsing this repo, the depth of recursion can sometimes get quite substantial:

Spinning up so many threads during edits and type checks can't be great for performance. But things can get abysmally slow when an exception is thrown deep into the recursion that is not caught early but percolates slowly through all the threads.

I'm not sure that's what actually happens, but people are reporting awful performance and one exception that comes to mind is the cancellation that Cancellable.CheckAndThrow() raises. I'll add some telemetry to make sure it's not a problem.

[majocha]

Some AI generated benchmarks, recursion 5000 iterations deep, maxDepth 100:

original cancellable with GuardCancellable

| Method                      | Mean         | Error       | StdDev     | Gen0        | Gen1        | Gen2        | Allocated     |
|---------------------------- |-------------:|------------:|-----------:|------------:|------------:|------------:|--------------:|
| SimpleRecursion             |     4.281 ms |   0.6494 ms |  0.1686 ms |    101.5625 |     46.8750 |      7.8125 |     848.43 KB |
| MutualRecursion             |     2.106 ms |   0.2575 ms |  0.0398 ms |     66.4063 |     15.6250 |      3.9063 |     658.57 KB |
| TryWith                     |     4.017 ms |   0.4133 ms |  0.1073 ms |    101.5625 |     46.8750 |      7.8125 |     848.47 KB |
| TryFinally                  |     4.051 ms |   0.2525 ms |  0.0391 ms |    101.5625 |     54.6875 |      7.8125 |     848.53 KB |
| StringSimpleRecursion       |    26.566 ms |   1.2149 ms |  0.3155 ms |   2781.2500 |   2656.2500 |    968.7500 |   25399.08 KB |
| DeepRecursiveExceptionCatch | 3,114.110 ms | 207.3326 ms | 32.0849 ms | 891000.0000 | 890000.0000 | 890000.0000 | 3868135.22 KB |

resumable Cancellable

| Method                      | Mean        | Error     | StdDev    | Gen0      | Gen1      | Gen2     | Allocated   |
|---------------------------- |------------:|----------:|----------:|----------:|----------:|---------:|------------:|
| SimpleRecursion             |    202.0 us |   3.35 us |   3.58 us |   55.4199 |   41.5039 |  41.5039 |   647.13 KB |
| MutualRecursion             |    227.6 us |   3.61 us |   4.16 us |   55.4199 |   41.5039 |  41.5039 |   647.13 KB |
| TryWith                     |    211.3 us |   3.50 us |   3.74 us |   55.4199 |   41.5039 |  41.5039 |   647.19 KB |
| TryFinally                  |    201.8 us |   2.57 us |   2.96 us |   55.4199 |   41.5039 |  41.5039 |   647.23 KB |
| StringSimpleRecursion       | 12,456.9 us | 132.29 us | 152.35 us | 2781.2500 | 2718.7500 | 984.3750 | 25268.39 KB |
| DeepRecursiveExceptionCatch | 17,593.3 us | 151.60 us | 174.58 us |  656.2500 |  125.0000 |  62.5000 |  8307.18 KB |

Memo to myself mostly: the approach to get unlimited recursion in a future AsyncMethodBuilder based async2 resumable CE builder is similar to what's going on here.

In Bind, occasionally yield before executing the bound awaitable to limit the stack use.
When there is deep recursion, cut the stack traces short by memoizing / reusing ExceptionDispatchInfo instead of using the built in SetException, which could quickly eat up all of the RAM.