Support different coroutine models in workflows and activities

[cretz]

Describe the solution you'd like

Need to several things:

• May need to slightly abstract workflow concurrency impl to support (but may not)
• Update Kotlin project to add support for Kotlin coroutines in workflows and activities as Kotlin suspend fun calls (may need to be opt-in in some way). There is an internal POC implementation from @mfateev we can leverage here.
• Create a new Java 21+ only "temporal-virtual-threads" project that uses virtual threads for workflow concurrency and runs activities in virtual threads (may need to be opt-in in some way)

This is kinda a big project, so some discussion should happen first. The above is just speculation about what to do.

[rocketraman]

As a Kotlin user who is getting started with Temporal, I would love to see this. Calls like Workflow.sleep() block a platform thread, which isn't scalable and is annoying in principle even where its not an actual scalability issue :-)

Kotlin coroutines, and more recently with the release of JDK 21 and Java virtual threads, are a perfect solution to this problem as they take up almost no resources while blocked on workflow sleep or activity calls.

I know nothing about the Java SDK internals, but looking at it from the outside in, the most basic abstraction of an async call is a callback. These are easy to bridge to suspending calls in Kotlin, and presumably to Java fibers. So if the SDK exposed async versions of its API that took a callback to resume the workflow execution, this would be easy to turn back into regular synchronous but non-blocking code via coroutines, and presumably fibers.

Issues which are probably duplicates or at least related to this one, based on the search I just did:

• https://github.com/temporalio/sdk-java/issues/1849
• https://github.com/temporalio/sdk-java/issues/778