Ensure reasonable behavior on exceptions during suspension

[jakobbotsch]

There are two possible source of exceptions during suspension:

• Allocation of the continuation instance can throw OOM
• Restoration of ExecutionContext calls into user code through ExecutionContext.OnValuesChanges (removed in Save/restore contexts for custom notifiers #121743)

We should ensure that something reasonable happens in these cases.

[dotnet-policy-service]

Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch
See info in area-owners.md if you want to be subscribed.

[jakobbotsch]

@stephentoub For task-based async what is our stance on OOM happening when the state machine is boxed? It seems like it is basically not recoverable for the user, but I don't think we fail fast or anything like that, right?

[stephentoub]

@stephentoub For task-based async what is our stance on OOM happening when the state machine is boxed? It seems like it is basically not recoverable for the user, but I don't think we fail fast or anything like that, right?

On some of these code paths, in particular where user code could possibly run, we catch any unexpected exceptions and queue them to be re-thrown on a thread pool thread, such that when they then go unhandled, by default the process will crash. I don't believe we have such catches for system code, though, and thus it wouldn't handle all cases where allocating the state machine box OOM'd.