Make blocking APIs optionally async

[kevinmehall]

DeviceInfo::open, Device::from_fd, Device::set_configuration, Device::reset, Interface::set_alt_setting, Interface::clear_halt all perform IO but are currently blocking because the underlying OS APIs are blocking.

list_devices,list_buses, Device::claim_interface Device::detach_and_claim_interface theoretically don't perform IO, but are also included here because they need to be async on WebUSB.

The IoAction trait allows defering these actions to the thread pool from the blocking crate when used asynchronously with .await / IntoFuture, or directly runs the blocking syscall synchronously with a .wait() method.

Open question: Should the dependency on blocking be behind a cargo feature, and if unset, should IoAction not impl IntoFuture or should it return a dummy Future that runs synchronously?

[Yatekii]

Personally I would completely forego blocking variants of those methods and make all of them async. The readme states Async-first and I would honor that claim. I do not see why we need a ::wait() when we can just .await the future. An async executor is required anyways for the actual read/write methods.
And we get to save one crate by default ;)

[kevinmehall]

The blocking dep (or tokio) is required to make these async either way -- it's not recommended to do something blocking from an executor thread, so this uses blocking to move the synchronous syscalls onto a threadpool, like tokio and async-fs do for synchronous filesystem APIs.

But then it seems kind of silly to do what is effectively block_on(unblock(|| x())) to make another thread do it and then wait for it, when you could just call x(), so that's what IoAction is.

[Yatekii]

Fair point :) That's actually a really nice way to do this :)

I think we can merge this as is :)

[Yatekii]

How are we looking on this? :) I would love to round up my WebUSB backend PR :)

[kevinmehall]

Renamed it, but I think it's ready.