Fix usage of startCoroutineUninterceptedOrReturn

[nomisRev]

In #2783 we replaced startCoroutineUninterceptedOrReturn to createCoroutineUnintercepted + resume(Unit) but this creates an additional Continuation state-machine nested inside the existing state-machine and thus causing a lot of overhead. This overhead is occurring potentially on every fold, so not ideal.

While investigating if the issue of startCoroutineUninterceptedOrReturn was in our code, or in the compiler I discovered that it was indeed a mistake in our code.

The problem happens in following sequencing where we run the Effect<R, A>.

suspendCoroutineUninterceptedOrReturn { cont ->
  val token = Token()
  val effectScope: EffectScope<R> = ...
  
  try {
    suspend { transform(f(effectScope)) }
      .startCoroutineUninterceptedOrReturn(FoldContinuation(token, cont.context, cont))
  } catch (e: Suspend) {
    if (token == e.token) {
      val f: suspend () -> B = { e.recover(e.shifted) as B }
      f.startCoroutineUninterceptedOrReturn(cont)
    } else throw e
  }
}

1. We create the EffectScope and the Token
2. We create the program suspend { transform(f(effectScope)) }
3. We start the computation with startCoroutineUninterceptedOrReturn.

startCoroutineUninterceptedOrReturn immediately returns COROUTINE_SUSPENDED, B or throws an exception.
If COROUTINE_SUSPENDED is returned then we have to complete the cont using resume. If COROUTINE_SUSPENDED is returned it also means we'll go inside the FoldContinuation path.

In the original code we did not catch any immediate exceptions, meaning we were throwing an exception within suspendCoroutineUninterceptedOrReturn where we already returned COROUTINE_SUSPENDED earlier. Instead we need to capture the exception, and pass it to cont#resume or the exception will get lost in the Coroutine state machine.

when (val res = f.startCoroutineUninterceptedOrReturn(parent)) {
        COROUTINE_SUSPENDED -> Unit
        else -> parent.resume(res as B)
}

[nomisRev]

Tests for catch and attempt in #2782 exposed another bug.. The Throwable path was not properly covered everywhere, the fix and a test for it has also been included in this PR. It touches upon the same area, and involves similar code.

I can split it into a second PR if that is better for history/reviewing.

The problem:

Not the entire Throwable path was covered, and thus error lambda was sometimes not applied and the exception was thrown even though it was handled in the error lambda. The fix sequences the error lambda correctly.

[raulraja]

thanks @nomisRev

[i-walker]

👏🏾