testing: Panic propagation for test code

[kstrafe]

Related issue: #2699.

Summary
The proposal aims to improve the testability of applications and libraries which spawn tasks internally by creating a new scheduler that doesn't capture panics.

Motivation
Tokio tasks mimic std::thread behavior by capturing panics and only propagating these when the associated JoinHandle is joined. The usage of OS-level threads and tokio tasks however differs in the sense that applications and libraries may liberally spawn the latter, whilst usually making a thread pool of the former.

To make good tests of such libraries and applications we typically avoid threading at all to remove nondeterminism, however, with tokio this might not be possible. We need to allow tests to fail on panics in detached tasks to thoroughly test these libraries and apps.

Proposal
The proposed changes are:

impl Builder {
    fn new_test() -> Builder { ... }
}

In addition to copying the basic_scheduler code but changing the way spawn constructs a harness, in this case, harnesses are constructed with an alternative vtable where poll does not capture panics.

Changes for the end-user of Tokio
This change is an additive feature put behind the rt-test flag. It does not impact existing tokio users in any way, nor does it impact performance by not adding any new branches or extra code to run for those who do not use the test scheduler (with the exception of a few matches in the runtime, but that should be negligible). The test scheduler yields a Runtime object such that the API is unchanged.

Risks
Risk of breaking API if this scheduler is removed.

Open questions
Running the test scheduler in different threads may nondeterministically cause a panic to propagate in the thread that runs a future that happens to panic. This makes panics appear in an unspecified thread. Is this desirable?

Can this cause UB due to the panic happening inside the vtable call? Are there invariants that must be upheld?

It's not yet known what other features we want to add to the test scheduler, or whether we want #[tokio::test] to use the test scheduler.

[MikailBag]

As was mentioned on original thread, such an API can be footgun in presence of multiple threads or muktiple block_ons.

I propose making a new type TestRuntime, which does not expose APIs that are dangerous for ones' feet (i.e. always single thread and no block_on allowed).

Alternatively, Runtime in test mode can just panic in those risky situations.

[Darksonn]

Closing in favor of #4516.