Binary compatibility regression/breakage between Paho 1.3.1 and 1.3.2

[chainq]

Describe the bug
While introducing MQTTAsync_connectOptions (MQTC) structure version 7, the order of some fields introduced in version 6 changed. This is caused by the addition of the field httpHeaders in the middle of MQTTAsync_connectOptions structure. This means binaries which were compiled against v1.3.1 headers and use v6 of the structure, may return a MQTTCLIENT_BAD_MQTT_OPTION in MQTTAsync_connect when running against v1.3.2 of the library. (This actually happened in our use case.)

To Reproduce
Build a binary against v1.3.1 headers which uses v6 of the MQTTAsync_connectOptions structure, even if it just sets the MQTTv5 fields at the end to NULL, then try to run it against a v1.3.2. MQTTAsync_connect should fail with MQTTCLIENT_BAD_MQTT_OPTION.

Expected behavior
Well, I'd expect this not to happen, but it did. The offending commit is 7ed1672

Environment

• OS: Linux, ARMHF, but it should be OS and arch agnostic, really...

Additional context
Not sure how to fix this, if at all possible... If the structure order is reversed pre-1.3.2, then anything compiled against 1.3.2 will break with future library updates.

[icraggs]

Yep, as in #887 - unfortunately I missed that in a PR. I would re-tag with the fix but it seems that's not acceptable so it'll be fixed in 1.3.4, or that's my current plan.

[chainq]

Sorry, I missed the previous report, when I searched through the tracker for this issue. Good to know it's known, and there's a plan to roll out a fix, thanks. 👍

[icraggs]

I've added the fix to the master branch. I plan to tag 1.3.4 later today or tomorrow.