Nonblocking Subscribe/Unsubscribe

[thedevop]

Is your feature request related to a problem? Please describe.
In a high volume environment, the blocking nature of subscribe/unsubscribe creates a bottleneck.

Describe the solution you'd like
Add SubscribeWithOptions and UnsubscribeWithOptions like PublishWithOptions. This ensures the order is preserved hitting the wire, but without holding up the application waiting on response. It can either return result via a callback or a channel.

Describe alternatives you've considered
Call subscribe/unsubscribe in Go routines, however, this cannot guarantee the order.
Subscribe/Unsubscribe cannot be mixed in a single batch call.

[MattBrittan]

PublishWithOptions does not currently provide any notification that a message has actually been sent, it just retuns without waiting for a response (if the connection has been setup properly, and the session store is persistent, then it's reasonable to assume it will be sent at some point).
I'm open to this change, but it's not something I plan on implementing myself. One complicating factor is determining what to do when the connection is lost (and whether such publish requests should survice an application restart).

[thedevop]

In my use case, the subscription does not need to survive connection lost. A new paho client will be created, and the application will manage the subscriptions. I will provide an implementation for review.

[MattBrittan]

In my use case,

That's the challange because the library needs to support a range of use cases (I'm often surprised by how the library is used!). I think that, at a minimum, the callback would need to be called (passed some kind of error) for all pending requests when the connection is lost (otherwise users are likely to be left with goroutines waiting on something that will never happen).