Bump tokio and move to std Future (async/await)

[udoprog]

I've been tinkering with bumping this crate to the upcoming std future and tokio to make sure it's ready when both are released.

My thinking here would be to:

• Get rid of the reactor. Using async functions and blocks directly is more ergonomical than using callbacks.
• Convert all existing futures and streams in place first, then see if there's any opportunities to improve APIs.

I was hoping to track progress here.

[8573]

Using async functions

This would mean raising the minimum required Rust version, right?

[udoprog]

@8573 Yes. As well as a major API break.

[udoprog]

Started working on it here: https://github.com/udoprog/irc/tree/tokio-bump

I did an initial pass where I tried to maintain the existing API, but it didn't make much sense to me.

• Dropped the use of ClientExt in favor if tiny bit of duplication in ClientState.
• Renamed IrcClient to Client.
• Renamed PackedIrcClient to PackedClient.
• Renamed error::IrcError to error::Error.
• mockstream is not up-to-date with unstable tokio, so had to drop that for now. Tests don't run until that has been implemented.
• Removed most things associated with the reactor.
• ClientStream drives the stream for outgoing messages by default, unless it has been taken from the Client through Client::outgoing.
• You can access a thread-safe sender through Client::sender, which uses the outgoing queue for sending messages.
• Switched mutexes and locks to use parking_lot.

You can see the new API in-use in the build-bot bin. I'm considering making the send future part of the client stream instead of having it be a separate thing. Alternative have it be a thing that can be taken out of the client similarly to how stream is right now. This is done.

Examples ported:

• multiserver

[udoprog]

Done since #184 was merged