Preserve binary compatibility with TestScope.runTest(Long)

[dkhalanskyjb]

Fixes #3673

[qwwdfsad]

Shouldn't it target develop?

[dkhalanskyjb]

It should.

[qwwdfsad]

On the one hand, I'm delighted to know that kotlinx-coroutines-test provides enough value to be used in compose test utilities even in its experimental state. On the other hand, it's a bit terrifying as we have to care about backwards compatibility for experimental API even more

[dkhalanskyjb]

Yeah, I, too, was taken aback. I knew people depended on experimental functions, but I thought the experimental + tests would be the one area where production-like stability guarantees are unnecessary. Alas, we seem to be firmly in the https://xkcd.com/1172/ territory.

[arkivanov]

Perhaps, a library shouldn't use any experimental API, to avoid this kind of problems? Unless the library itself is experimental.

[qwwdfsad]

Depends on the library. It's okay to use it as long all available API depending on this API is also marked experimental.

For example, we had a stable delay(long) function and @ExperimentalStdlibApi delay(Duration) when duration was experimental.