Performance smoke-tests seem to be broken

[abelbraaksma]

Running ``CE taskSeq with nested deeply yield!`` (permalink, goes to original from the time of writing this) takes forever, but based on the non-delaying performance, it should be "just fine" and take an average time.

This test creates nested IAsyncEnumerable<'T>, themselves based on unit -> task<'T> functions to prevent having hot-started tasks. However, the test takes over 30s to finish (with the commented code enabled). Note that all of these tests deliberately use a randomly generated delay though Task.Delay.

Similar tests with many tasks that are not delayed do not have an issue.

[abelbraaksma]

See #16.

[abelbraaksma]

As per the referenced PR #17, and this MSDN article on Task.Delay, quote:

This method depends on the system clock. This means that the time delay will approximately equal the resolution of the system clock if the millisecondsDelay argument is less than the resolution of the system clock, which is approximately 15 milliseconds on Windows systems.

we can conclude: for smoke-testing randomly delayed tasks, this method may not be ideal. In #17 I'm introducing an alternative method, which has its own drawbacks, but for now it suffices.

Why these random delays?

Well, just writing this for posterity to myself, as for sure I'm gonna forget. We use this randomness to force wrong results if mutable data inside the tasks are accidentally run in the wrong order. A couple of tests show-case this scenario specifically, which happens if you treat List<task<''T>> incorrectly. See the PoC tests that test the "wrong way" to do this (which, unfortunately, happens quite often in code in the wild..., waiting to randomly crash).

More importantly, if we make a mistake in the resumable code, this method is quite likely to catch it.

[abelbraaksma]

This has been fixed in #17, see there for some more insights.