Reconsider the abstract return type in AsyncClient::get_stream()

[fpagliughi]

From @ryankurte in #66:

just a heads up that the abstract return type here makes embedding the client in higher-level objects a bit of a pain, it might be easier to just return the mpsc::Receiver as with the prior version (or to implement Stream on the Client object, but, same difference really)

[ryankurte]

i wrote a wrapper to do this here, though having more async experience under my belt i would now lean towards the return a concrete channel approach rather than implementing Sink/Stream (though they are not exclusive) as it tends to be easier to compose.

[GopherJ]

I personally think channel is not a good idea, because sometimes mqtt can have massive incoming messages for realtime computing purpose.

If the consumer doesn't perform quickly enough, the message will be blocked and unable to be sent

[fpagliughi]

Well it's optional to configure the client to queue the incoming messages. The application can register it's own callback handler and manage the messages itself.

But you need to remember that the messages arrive via callback from the internal C lib on a library thread. You need to deal with the message as quickly as possible and allow the thread to go back and process incoming traffic. Clearly an optimal solution in most cases it to just queue the message so that another thread can handle it. This is particularly appealing on a multicore CPU where one core can be used by the library and another one (or two, or three, ...) can be employed to process the messages.

So a channel may be a good solution, even in cases of high throughput. But you always have the option to write the callback yourself to do something more performant.