Investigate possibility to avoid kotlinx.coroutines dependency

[qwwdfsad]

Currently, Dokka actively depends (and exposes in public API via AsyncSourceToDocumentableTranslator) on kotlinx.coroutines for particular analysis tasks.

Historically, it was done as the natural way to speed up the rendering stage because every declaration (function, property, constant etc.) had its own page, and each page contained navigation data (thus the IO contention).
This no longer holds true, but coroutines are still here.

It has multiple downsides:

• Taking into account Dokka's internal coupling (=> inability to have a clear boundary on what should and shouldn't be thread-safe), it leads to classic concurrent bugs: Deadlock in Rendering stage #2926, java.io.IOException in FileWriter copyFromDirectory() #2698, FileWriter is not thread safe #2308 that are hard to prevent and test
• It contributes non-necessary dependency to the Dokka (whatever isolation mechanism we'll choose, it's still a bunch of classes to load and compile)
• It doesn't interfere well with workers' API. Use Gradle Worker API #2903 will bring not only workers but also natural Gradle-level parallelism, meaning that an additional layer of parallelism within individual tasks is likely to slow down the overall execution.

Ideally, we should prototype the solution (note that it couldn't be "coroutines in single-threaded mode", it has to be a complete removal) and measure the potential impact -- e.g. compare execution times of individual tasks on stdlib and kotlinx.coroutines, and decide whether slowdown is acceptable

[aSemy]

I have experimented with this locally, and anecdotally I find it improves performance in the Dokkatoo tests (which use the Gradle Worker API).

I prototyped it by find/replacing the coroutines functions with the run {} scope function

• launch { ➡ run {
• async { ➡ run {
• coroutineScope { ➡ run {
• etc...

and fixing any resulting issues.

I could share my work in a PR if it would help?