[v3] Update and/or reimport crossbeam_channel crate

[vincentdephily]

While switching to v3 branch I was pleased to see that callbacks had been replaced by a Receiver<Notification>, but quickly ran into compilation problems: either I tried to use crossbeam_channel::Receiver and the compiler would complain that it expected crossbeam_channel::channel::Receiver, or I tried to use crossbeam_channel::channel::Receiver and the compiler would complain that the channel module was private.

I fixed that by downgrading crossbeam-channel from ~0.3 to ~0.1 in my Cargo.toml, to match the version that rumqtt depends on. A few issues with that fix:

• The fix isn't obvious
• That fix wouldn't have worked if my crate had already been using the more recent version of crossbeam-channel explicitly somewhere.
• The 0.1 version is really old at this stage and shouldn't be required by a recent lib.

Beyond the obvious "upgrade crossbeam-channel dep in rumqtt", I think a more future-proof solution would be for rumqtt to re-export the Receiver struct. That way, rumqtt users would use rumqtt::Receiver instead of use crossbeam_channel::Receiver and be insulated from API changes, letting rust deal with the issue of figuring out which bit of code uses which crossbeam version.

Another thing that might help is putting that Receiver back inside MqttClient and providing a method to clone it. I'm not 100% sure of that one, but I think it would reduce friction when using rumqtt.

[tekjar]

Upgraded. Will reexport once crossbeam's select! is tested

[tekjar]

Re-export done