Run "slow" tests as part of pull request checks

[tautschnig]

Description of changes:

The execution of this check takes less than 15 minutes, which is well below our overall CI time for pull requests (around 45 minutes). Making these tests part of pull request checks will ensure we catch problems early.

Resolved issues:

n/a

Related RFC:

n/a

Call-outs:

n/a

Testing:

• How is this change tested? Part of this pull request.

• Is this a refactor change? Sort of - refactoring of CI.

Checklist

• Each commit message has a non-empty body, explaining why the change was made
• n/a Methods or procedures are documented
• Regression or unit tests are included, or existing tests cover the modified code
• My PR is restricted to a single feature or bugfix

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 and MIT licenses.

[zhassan-aws]

Thanks @tautschnig. As far as I recall, the slow tests suite was introduced for the purpose of running regressions that take too long for CI. If particular tests are no longer time consuming, I think we should move them to be part of the regular regression suite. But I think we should keep the slow tests workflow for cases that take too long. Alternatively, we can any long running tests tests to the performance regression suite so that we can track any performance improvement.

[zhassan-aws]

Also worth mentioning that there are many harnesses in the tokio-proofs regression that are currently disabled because they ran for more than 2 hours. I just tried one of them and it completed in 3 seconds (after updating the unwind to 12). So we should revisit them and check which ones we can enable.

[tautschnig]

It seems the tests themselves (tokio-proofs) take between 2 to 3 minutes, but then I don't know what those tests are specifically testing - I could just move them to a new folder under tests/ (tests/tokio-proofs), but I don't know whether that's justified. Also, in doing so tests/slow would be left empty, so I'd have to add a dummy file to keep the folder in git.

For the moment I took a different approach and moved the runs from "Nightly" to run-on-push-to-main: there is nothing in these tests where a different day would make a difference, it's all about the code we have in the repository. So we should detect problems as early as possible, and if we think that (eventually) those tests will take too long for pull-request CI then let's run them immediately after the merge so that we know as soon as possible when we messed up.

[celinval]

I agree with @zhassan-aws. We should move those harnesses out of the slow folder. If that leaves us with no slow harness, then we should change this job to not fail if there is no test.