Provide stack for suspended coro in test timeout

[fjetter]

This allows us to retrieve some superficial information in case of a test timeout. Typically we only receive a plain timeout. This will print the frame the coro is currently suspended upon timeout. I hope this provides at least some indication of why a test is stuck. It does only show one frame level, though. Nested stack is not available according to the asyncio implementation. I figured this is still better than nothing. ¯_(ツ)_/¯

An example output looks like this when running the new test w/out the pytest exception assert

E               asyncio.exceptions.TimeoutError: Test timeout.
E               Stack for <Task pending name='Task-44' coro=<test_provide_stack_on_timeout.<locals>.inner_test() running at /Users/fjetter/workspace/distributed/distributed/tests/test_utils_test.py:382> wait_for=<Future pending cb=[<TaskWakeupMethWrapper object at 0x153ca1100>()]>> (most recent call last):
E                 File "/Users/fjetter/workspace/distributed/distributed/tests/test_utils_test.py", line 382, in inner_test
E                   await asyncio.sleep(sleep_time)

[crusaderky]

There are deterministic regressions:

FAILED distributed/tests/test_scheduler.py::test_scheduler_init_pulls_blocked_handlers_from_config
FAILED distributed/tests/test_utils_test.py::test_gen_cluster_legacy_implicit
FAILED distributed/tests/test_utils_test.py::test_gen_cluster_legacy_explicit

[fjetter]

I removed the test_gen_cluster_legacy_implicit / test_gen_cluster_legacy_explicit since I have no idea what they are supposed to test. I assume it's about the gen.coroutine call at the beginning. However, I don't see a reason to not define a gen_cluster decorated function as async and instead raise now.

[crusaderky]

This looks good. The only issue I have with it is that it will mask TimeoutError's coming from inside the actual test function. In theory we could fix it by inspecting the stack trace and making sure that it was raised by utils_test.py. Unsure if it's worth the extra complexity though.

[fjetter]

This looks good. The only issue I have with it is that it will mask TimeoutError's coming from inside the actual test function. In theory we could fix it by inspecting the stack trace and making sure that it was raised by utils_test.py. Unsure if it's worth the extra complexity though.

I am raising the TimeoutError as raise TimeoutError(...) from None to strip further context since in most situation this is just overly verbose spam. If there are cases where this provides useful information, we can just raise with cause