Handle Orphaned Operations

[vishnureddy17]

related issue: #134

Here's a proposal for a design to handle orphaned operations (PUBLISH w/ QoS >0, SUBSCRIBE, and UNSUBSCRIBE).

This would allow the user to get back the result of an operation after a timeout. More importantly, this allows us to kick off a PUBLISH operation in the background when connecting with an existing session comes into the picture.

It seems to work as intended, and I'm happy to write some tests for it. However, I wanted to get feedback on this before I go through the effort since this is a substantial change and I'm not sure if this is the direction the project would be willing to take.

The basic idea is that PUBLISH w/ QoS >0, SUBSCRIBE, and UNSUBSCRIBE are handled inside an internal goroutine that puts the result in a channel when it is received from the server. The user-facing Publish(), Subscribe(), and Unsubscribe() functions call the internal functions. If the context is cancelled before the internal goroutines return a result on the channel, the user-facing function returns with an error and the operation is still tracked in the background. There are user-configurable callbacks to get the results for orphaned operations.

[vishnureddy17]

After working with this design for a bit, I actually think this is not a good approach. By putting each publish into its own goroutine it is difficult to guarantee ordering that the MQTT spec requires.

[vishnureddy17]

Going to close this, I don't think this is a good path to go down.