Port over FB MQTT handling logic across resets, plus maintain message_response_waiter across MQTT resets.
Currently after MQTT reconnects the next waiting message sends immediately, then gets it's message_response, then another message_response comes in for the command sent immediately before the MQTT reset. This change should block after MQTT reconnects until the message_response from the last command comes in, then it can go about it's way.
Not sure how to test it though, need to simulate an MQTT reset? Works fine on the happy path.
Port over FB MQTT handling logic across resets, plus maintain message_response_waiter across MQTT resets.
Currently after MQTT reconnects the next waiting message sends immediately, then gets it's message_response, then another message_response comes in for the command sent immediately before the MQTT reset. This change should block after MQTT reconnects until the message_response from the last command comes in, then it can go about it's way.
Not sure how to test it though, need to simulate an MQTT reset? Works fine on the happy path.