Fix wait_for_publish that could hang for QoS=0 message

[PierreF]

If reconnect() is called (which happen on auto-reconnection or on first connection done by loop_forever), any pending QoS = 0 message were dropped without unblocking wait_for_publish().

We now ensure wait_for_publish() is unblocked and raise RuntimeError with MQTT_ERR_CONN_LOST

Fix #549

[akx]

Should there be a test for this?

[akx]

Suggested change

[akx]

Is there some subtlety here as to why old_queue is grabbed first and this is only done exactly after self._out_packet has been reallocated? If not, it feels like

Suggested change

	# Before dropping all out_packet, ensure any QoS == 0 message info get
	# marked as MQTT_ERR_CONN_LOST or the wait_for_publish() could hang forever
	old_queue = self._out_packet
	self._out_packet = collections.deque()
	for pkt in old_queue:
	if pkt["command"] & 0xF0 == PUBLISH and pkt["qos"] == 0:
	pkt["info"].rc = MQTT_ERR_CONN_LOST
	pkt["info"]._set_as_published()
	# Mark all currently outgoing QoS = 0 packets as lost,
	# or `wait_for_publish()` could hang forever
	for pkt in self._out_packet:
	if pkt["command"] & 0xF0 == PUBLISH and pkt["qos"] == 0:
	pkt["info"].rc = MQTT_ERR_CONN_LOST
	pkt["info"]._set_as_published()
	self._out_packet = collections.deque()

would be the more obvious way to write this.

(self._out_packet.clear() would also save some allocations.)

[PierreF]

The reason way for what happen if a publish() if call during reconnect(). It would end in the new _out_packet or be marked at published... but well it's not very nice.

I'll check, but I think it better in all aspect to close the socket, then process the _set_as_published + clear the out_packet queue, because once closed we don't add message to out_packet.