Add support for embedded_hal_async::digital::Wait

[cdunster]

This PR adds support for the async Wait trait from the embedded-hal-async crate.

[dbrgn]

@cdunster hi, there are new conflicts introduced by other merges. Would you mind updating your branch? Thanks.

[cdunster]

Hi @dbrgn, I've updated my branch. Thanks for looking into this PR.

[avsaase]

I gave this PR a try and it works well. Would be possible to add a configurable delay before these async functions resolve? In my code I use timeouts for control flow so I need a way to make these futures not resolve immediately.

EDIT: This is what I had in mind: https://github.com/dbrgn/embedded-hal-mock/commit/7f69d31daab1671f82bd34c21adc95bf7ff39296.

[cdunster]

Hi @avsaase, that looks good to me. I would prefer to make the delay an Option<Duration> so that we could keep wait_for_state and wait_for_edge for use without a delay and then add wait_for_state_with_delay for use with the delay.

The only "problem" I see is that this makes tokio an official dependency of this crate (instead of just a dev-dependency) I don't personally have an issue with this but I'm not sure if it aligns with @dbrgn's goals for this crate? Maybe we could put it behind a feature flag to make it opt-in but I think that's up to @dbrgn.

[dbrgn]

@cdunster looking great, thanks!

Regarding the configurable delay: If such a delay would be added, is that something that should be added to other async mock method calls as well, not just digital pins?

On the other hand, this method is explicitly about waiting, so a configurable wait time might make sense. However, the point about the tokio dependency is a valid one. Ideally, we'd have an executor-independent async sleep implementation, but I think that's not currently possible in Rust, right?

In any case, I'll rebase and merge this PR for now. I'll tag a new release soon, but more features (even breaking changes) can always be added. If you're interested in a configurable delay, feel free to open a new PR, where it can be discussed.

Edit: One downside of adding tokio as a dependency would be that it's harder to keep the MSRV. Tokio has a rolling MSRV, we currently have a fixed one.