add deeply-nested-async test

[lcnr]

r? @Mark-Simulacrum

cc @tmandry

[Mark-Simulacrum]

How long does this currently take for you to run locally? We need it to run in roughly one second (at least after any potential patches in flight).

Is this sufficiently different from the await call tree test we already have?

[lcnr]

lcnr@lcnr-pc:~/wtf$ cargo +feca2c229e209ceda1eda7306e6ea9ee0aaa9305 build
   Compiling wtf v0.1.0 (/home/lcnr/wtf)
    Finished dev [unoptimized + debuginfo] target(s) in 1.00s

I am not even joking

[lcnr]

The current await call tree test did not catch that regression.

rust-lang/rust#76928 improves the performance of this test from 3.5s to 1.0s while the current benchmarks were all mostly neutral, so I think this is sufficiently different to other benchmarks

[kellerkindt]

A little note about the author of the test would have been appreciated :3

[kellerkindt]

Yay, thanks 😄

[Mark-Simulacrum]

Thanks for adding docs on deeply-nested-closures as well. It might be good to try and understand why await-call-tree does not catch this. Maybe this new benchmark is just universally better and we should drop await-call-tree? (2 "micro" benchmarks testing the same thing is not great; it adds overall suite runtime and confuses our results).

I think the main difference is that this has arguments to the async functions and the other one didn't...

[lcnr]

hmm, I think deeply-nested-async covers strictly more than await-call-tree but I am not completely sure about that.

Would it make sense to keep both of them for a short while and then remove await-call-tree if we don't catch any regressions/improvements which only affect one of these tests?

[Mark-Simulacrum]

I'm sure we'll be waiting a long time before we realize that we've not seen anything :)

I'll merge for now though.