Add SendFut::into_inner.

[NathanSWard]

This is the first step for adding a send_timeout_async and send_deadling_async.
This provides the ability to consume a SendFut returning its contained value if the value has not yet been sent.

[zesterer]

This looks good to me! I initially turned my nose up at the name into_inner, but on second thoughts I think you're right that this does actually follow the conventions set by other types in the Rust ecosystem.

[zesterer]

At least now, building a timeout on top is a relatively trivial job. In terms of implementing that, I think the most lightweight and sensible solution - based on a cursory reading - is to pull in the async-io crate as an optional dependency and use its timers (perhaps behind some sort of async_timeout feature in flume). What do you think?

[NathanSWard]

Yep, it mostly just depends on how you want the API to look either
A) having the function be marked async

pub async fn send_timeout_async(&self, message: T, dur: Duration) -> Result<(), ErrorType>;

B) having the function return some concrete type that implements Future

pub fn send_timeout_async(&self, message: T, dur: Duration) -> TimeoutFut;

In the case of A we could just use async_std::future::timeout I believe, and then in case B, async-io would be a good solution yes!

[zesterer]

I think B is probably the way to go. It's an underrated thing, but being able to name the type of a feature is occasionally very important, particularly if you're building an API on top of the thing.

[NathanSWard]

@zesterer Do you want these as separate MRs, or should I add the timeout functions here in this MR?

[NathanSWard]

It looks like the actual implementation of the _async functions make take a bit of extra work.
Notably, the Hook type has a todo comment: // TODO: Investigate some sort of invalidation flag for timeouts.

When writing tests, for the implementation, there is a panic coming from the fire_recv function which always unwraps the inner value.