Support for asynchronous parking

[Wulf0x67E7]

Summary

Added support for asynchronous parking to parking_lot_core behind a feature flag, and in the process also made all the (un)park-methods reuse their queue manipulation logic, as well as added a future extension trait and methods to util.

Motivation

I was recently playing around with synchronization primitives and sync/async interop. While trying to implement something using parking_lot_core, I wanted to add async support, but realized that parking lot didn't support what I needed for that. I then thought that extending it myself would be a fun and doable project.

Changes

• Added feature "async"

• Added optional dependency "futures" (couldn't work out how to make it a feature dependent dev-dependency)

• Added function parking_lot_core::park_task

• Added ImmediateFuture utility trait, struct, and functions

• Refactored park and park_task to reuse shared queue manipulation logic

• Refactored the various unpark methods to also reuse the shared queue manipulation logic

• Extended the testing tools to also work with async and mixed sync/async operations and made it pass both normally and under miri

• Added documentation and comments for the new/refactored code

• [025af7e] Added dependency scopeguard = { version = "1.1.0", default-features = false }

Issues

• Full optional "futures" dependency instead of just dev-dependency
• [025af7e] park_task has even stricter safety requirements then park, namely that the resulting future can not be dropped or forgotten before being unparked or timed out.
• [025af7e] Because of that, when using park_task to implement e.g. an asynchronous-aware Mutex its unsafety cannot be fully mitigated unless you yourself are the one synchronously polling it to completion, which kinda defeats the point.

Notes

• [025af7e] Leaking the future from park_task, unlike dropping or forgetting, is actually fine and won't even block other things from making progress because ImmediateFuture ensures it cant yield while still holding the queue lock.
• [025af7e]Thinking about it now, leaking park_tasks ParkData at the beginning and then only "un-leaking" and dropping it at the end could fix the extra unsafety, but would require allocation and, obviously, risk leaking memory.
• The aproach used in [025af7e] to make park_task panic safe could also be applied to park.

[faern]

Highly related issues: #443, #86. Async support in parking_lot has been discussed before and closed as not in scope at least those times.