[kyo-reactive-streams]: Remove un-necessary sleep time in test cases

[HollandDM]

Originally, Async.sleep was used to mimic the real-life delay of a publisher/subscriber, but in the reactive-streams-tck test cases, it provides little to no benefit while significantly slowing down the overall test. Additionally, a quick look at fs2 and zio shows that they also do not use sleep in their test cases.

This PR takes it a step further by removing Async.sleep from all kyo-reactive-stream test cases. Since this feature is primarily about correctly combining effects, I believe that if individual components have been thoroughly tested, we can proceed with just the minimal testing.

Furthermore, because StreamSubscriber has two strategies, I initially duplicated the tests for both. However, I think it suffices to randomly choose one strategy for each test in the suite.

Overall, on my MacBook M3, the old tests took 1 minute and 37 seconds to run, while the new tests complete in just 34 seconds.

Aim to resolve #938

[fwbrasil]

could it be 100ms?

[HollandDM]

This is more like a keep alive effect, the whole fiber will be interrupted below in 10.millis. So i dont think duration here is that important

[fwbrasil]

Another way we can try to speed it up is by running tests in parallel. If you override fork := false in the specific SBT module, the tests will run start running in parallel but without forking JVMs for execution. If I'm not mistaken, SBT will pick up the number of cores as the parallelism. Since these tests seem to use little CPU, we could probably override it to use a higher concurrency but I don't recall the SBT config for that.

[HollandDM]

After some playing around, I figured there are 2 solutions:

1. To set fork := false like you said, this cases it will fork all other test to another JVM and run them sequentially. The downside is that if the test failed, so do the sbt process.
2. Tweak the concurrentRestrictions and parallelExecution, e.g:

Global / parallelExecution := true
Global / concurrentRestrictions := Def.setting {
      val par = parallelExecution.value
      val max = EvaluateTask.SystemProcessors
      Tags.limitAll(if (par) max else 1) ::
        Tags.limit(Tags.ForkedTestGroup, if (par) max else 1) ::
        Tags.exclusiveGroup(Tags.Clean) ::
        Nil
    }.value

concurrentRestrictions value is the default value taken from sbt codebase, but the Tags.ForkedTestGroup will be free from 1. This will run all the tests in parallel, there for kyo-reactive-streams tests won't block other.
I saw that sbt allow us to group the test cases into group, then decide the fork strategy for each. It bests to group every other tests to one group and kyo-reactive-streams tests to another one and fork them separately, but this will required us to "un-aggregate" the test task and build them manually (as far as i can tell, could be wrong), so it's quite hard to do compare to the 2 solutions above, WDYT?

[fwbrasil]

@HollandDM I tried the config you mentioned but it still executes sequentially. While debugging, I noticed the TCK tests end up waiting for the timeout in multiple scenarios to wait for potential new events. If I set new TestEnvironment(10L) in the constructor, the tests run in one second. Is that an option?

[HollandDM]

@fwbrasil weird, maybe testing environment only has 1 core?
Anw, if we can speed up the test by limiting the waiting time, then it should be good enough, let me update this.

[HollandDM]

I used Fiber.gather but it some time just got stuck, will do some more investigate later

[fwbrasil]

What's the goal here? Why not use parallelUnbounded? Fiber.gather is a recent addition, it'd be great if you could try to isolate in case there's an issue

[fwbrasil]

Can we merge this or are you're still planing to work on it? Thanks!