The coroutine states in the debugger are inaccurate when starts are undispatched

[dkhalanskyjb]

Undispatched starts of coroutines (with CoroutineStart.UNDISPATCHED or unconfined dispatchers (sorry, I myself got confused)) confuse the debugger.

fun weWantToUseSteppingInThisFunction() {
  println("A")
  delay(100)
  println("B")
}

runBlocking {
  launch(start = CoroutineStart.UNDISPATCHED) {
    weWantToUseSteppingInThisFunction()
  }
  println("C")
}

At point A, we'll see that the outer coroutine is considered to be running, whereas the inner coroutine is only "created" and doesn't even have a stacktrace associated with it.

This is not that big of an issue when browsing the list of running coroutines: we'll see that someone executes A, it's not a big deal that the slightly incorrect coroutine is doing that. When introducing stepping, this becomes a problem: given a breakpoint at A, we need a reliable way to say "run to B in the same coroutine." When the coroutine machinery thinks that A is executed by the outer coroutine, this becomes impossible.

Previous discussion: #3987 (comment)

[qwwdfsad]

I am not exactly sure what the desired behaviour is.

First things first, let's figure out "undispatched" coroutines behaviour:

suspend fun weWantToUseSteppingInThisFunction() {
    println("A")
    DebugProbes.dumpCoroutinesInfo().map {
        println("State: ${it.state}")
    }
    delay(100)
    println("B")
}

launch(start = CoroutineStart.UNDISPATCHED) { // or launch(Dispatchers.Unconfined)
    weWantToUseSteppingInThisFunction()
}

For the UNDISPATCHED case, it will print

A
State: RUNNING
State: CREATED

while for UNCONFINED it's

State: RUNNING
State: RUNNING

No matter the nesting statuses decision, the UNDISPATCHED behaviour is clearly a bug -- there shouldn't be any reasonable situations when we are within coroutine body but consider coroutine non-running.
The fix is most likely straightforward -- startDirect rightfully notifies the debugger about the creating, but not about the actual start, and it also bypasses coroutine intrinsics that could've done so for it. We can change it by notifying it right in the same place.

When the coroutine machinery thinks that A is executed by the outer coroutine, this becomes impossible.

If this is the root cause of our stepping problem, then we can agree this is a bug and fix it. But, if the problem lies in the fact that we have two nested running coroutines in the same thread, then this is uncharted territory where we'll have to find some solution because, depending on the angle you are looking at that, the outer coroutine might or might not be RUNNING and might or might not be SUSPENDED (note: transition to SUSPENDED is not a side-effect free action and also can confuse users when they expect outer coroutine not to suspend)