Fix flaky timeout test

[danielkec]

Seems like it can take more than 1 millis to finish onSubscribe on slower machine

Running TestSuite
Tests run: 2915, Failures: 1, Errors: 0, Skipped: 1401, Time elapsed: 133.362 sec <<< FAILURE! - in TestSuite
optional_spec104_mustSignalOnErrorWhenFails(io.helidon.common.reactive.MultiTimeoutNormalTckTest)  Time elapsed: 0.031 sec  <<< FAILURE!
java.lang.RuntimeException: Publisher threw exception (Async error during test execution: onSubscribe should be called prior to onError always) instead of signalling error via onError!
Caused by: java.lang.AssertionError: Async error during test execution: onSubscribe should be called prior to onError always
Caused by: org.reactivestreams.tck.TestEnvironment$Latch$ExpectedClosedLatchException: onSubscribe should be called prior to onError always
Results :
Failed tests: 
  MultiTimeoutNormalTckTest>PublisherVerification.optional_spec104_mustSignalOnErrorWhenFails:391 » Runtime
Tests run: 2915, Failures: 1, Errors: 0, Skipped: 1401
12:24:29,868 [INFO] parallel='none', perCoreThreadCount=true, threadCount=0, useUnlimitedThreads=false, threadCountSuites=0, threadCountClasses=0, threadCountMethods=0, parallelOptimized=true

Signed-off-by: Daniel Kec daniel.kec@oracle.com

[akarnokd]

Oh, the issue is with scheduling the timeout before calling the downstream's onSubscribe. I'll post a fix shortly.

[akarnokd]

https://github.com/oracle/helidon/blob/master/common/reactive/src/main/java/io/helidon/common/reactive/MultiTimeout.java#L100-L102

[akarnokd]

See #1674

[danielkec]

Closed in favor of #1674