Move to GH actions

[MrLotU]

Move to GH Actions instead of Circle CI. Also adds Swift 5.3 and 5.4 as test targets.

Checklist

• The provided tests still run.
• I've created new tests where needed.
• I've updated the documentation if necessary.

[MrLotU]

Not super happy with this solution, but from some checking the MacOS runners make this sleep last somewhere between 0.05 and 0.1 seconds, which makes these tests incredibly flaky. Locally they run just fine.

[MrLotU]

Any input appreciated. CC @ktoso

[ktoso]

We can introduce the concept of time dilation. We used to do this all the time in Akka where we had very slow CI machines and had to adjust timeouts on them for all tests. It's documented a bit here: https://doc.akka.io/docs/akka/current/testing.html#accounting-for-slow-test-systems

This means that we'd do: delay.dilated where dilated would be

var dilated: Double { 
  if <DETECT IF ON SLOW RUNTIME> 
    return self * /*dilationFactor (e.g: */ 2 // easiest to have this be set in an env var
  else 
  return self
}

So in the CI, env we'd just set the TEST_TIME_DILATION_FACTOR=10 or something that makes it happy :-)

WDYT?

[MrLotU]

If I understand correctly this would turn this test from sleeping for 0.05 seconds, to sleeping for 50. Which would than require to also update the asserts based on the time dilation, correct? In that case, would that not only make the problem worse?

In this case it's not a timeout that's messing things up, it's measuring the time a Thread.sleep takes, and on slow CI machines it takes longer than it's supposed to, resulting in "wrong" metrics.

[ktoso]

Yeah I wasn't all to clear I guess. In such tests we need to adjust the "expectation" rather than the sleep -- so we'd apply the dilated to the expectation that the time was smaller than something.

All such sleepy tests are pretty meh so let's just give it a good best effort :-)

[MrLotU]

@ktoso Decided on a new strategy to do these time based tests. Thoughts? 😄