Better support for large number of green-thread like things

[weinand]

TBD

(for now see discussion #159)

[connor4312]

cc @polinasok / @gregg-miskelly / @hyangah from the original issue

My experience with green threads come from Go. Thinking about the user experience, when debugging a Go program I would like to:

1. See how many threads are currently executing each line of code, like what pprof in Go gives.
2. Have ability to step into or introspect thread(s) on each line of code, i.e. issue a "pause" for a thread when it resumes.
3. 'Track' or 'isolate' a thread so I can easily step back into it. For example, if I have a websocket server I usually have at least one goroutine per connection, but might be interested in only debugging one of them. If the debugger supports it, being able to set a breakpoint so that it only hit by 'tracked' threads would be phenomenal.

The main protocol change is that threads would not be updated ambiently in an individually addressable way in the threads event. I think this is something we want to avoid since dealing with events for millions of threads could become problematic from a performance standpoint.

Perhaps instead the debug adapter could provide location metadata as in (1), and a mechanism to "realize" threads. Realization would happen when:

• a breakpoint is hit by a thread
• the ui requests an (arbitrary?) thread at a location to be realized

A thread would get a DAP threadId and should get threads events only after it's realized. This would allow (2) and (3). The UI could also request to "unrealize" a thread.

Something this doesn't cover is cases where additional metadata for threads, outside of location, is available. For example in Elixir/Erlang users might be want to explore the supervisor tree -- though I don't think this structure is relevant to m/any other languages.

[polinasok]

@aarzilli

[weinand]

@connor4312 since we already have an UI related issue for the "many threads debugging UI" in the VS Code repo, may I suggest that you copy your comment from above to #116109. Thanks!