chore: Update futures-preview to 0.3.0-alpha.17

[taiki-e]

Motivation

futures-preview 0.3.0-alpha.17 has been released that includes rust-lang/futures-rs#1706, rust-lang/futures-rs#1708, rust-lang/futures-rs#1709, rust-lang/futures-rs#1662, and rust-lang/futures-rs#1602.
This will probably unblock #1244.

Solution

• Bumps dependency versions.
• Changes tokio-futures to use futures_core::ready because ready! macro moved to futures-core from futures-util (Move ready! macro to futures-core from futures-util rust-lang/futures-rs#1699). (I didn't do this in other crates because futures-core dependency is optional)

[carllerche]

Thanks

[carllerche]

@taiki-e What do you think about adding feature flags to futures-core? I believe we (tokio) will only end up depending on the Stream trait and the ready macro.

[taiki-e]

@carllerche

I'm still not very clear about this as it is not clear how much stability the futures-core guarantees (rust-lang/futures-rs#1688 (comment), rust-lang/futures-rs#1634 (comment)), but I think we might be able to do these things:

• AtomicWaker(futures_core::task::__internal::AtomicWaker) - This isn't a public API, it's intended for use with channels and utils, so it can be an option.

• Spwan/LocalSpwan - I think many of the libraries that use futures-core don't use this (it is basically used only by the library that implements executors), so I think it's okay to have this as an option, but others may have different opinions.

• FutureObj/LocalFutureObj - This is intended to be used in the Spwan/LocalSpwan traits or no_std. I think if Spwan can be an option this can be an option too (AFAIK this is basically not necessary if crates target only platforms that can use Box).

[carllerche]

@taiki-e 👍