add simple API support for app MQTT pub retries

[scaprile]

#2689

• Should work as long as the id counter does not rollback (65536 messages sent while waiting to retransmit)
• Does not break current API

[cpq]

why do we need to keep it in opts?
can't we just do this?

uint16_t id = c->mgr->mqtt_id;

[scaprile]

mg_mqtt_pub() needs a way to know whether to:

• send a new id
• send a specific id and set the DUP flag

I modified it to make the decision based on the value of opts.id. If it is 0, it will create a new id. If it is !=0, it will use that id and set the DUP flag. The caller is responsible for keeping and clearing the id (and the message text for retransmission)

[cpq]

so that opts.id is used as a signal to set the flags, I see..
I feel a bit uncomfortable about it, seems too tricky..
What if we expose flags argument to the API ? is it used anywhere else but for this retransmission?

[scaprile]

The retransmission operation requires using the very same id of the former message, and, setting the DUP flag.
We need a way to do a retransmission instead of plain publish.

Using a new function was my first choice, that was discarded.

We can break the mg_mqtt_pub() signature by adding an extra argument, or two arguments.

• 1 argument: address of id holder, pub stores the id there and there's no need to hold it in options nor to pick it up from the manager. Hidden logic: we set the DUP flag for the user. Seems obvious to me, as one implies the other. Cons: the user has to provide a clean id holder or a NULL pointer if don't care (to simplify usage in usual conditions).
• 2 arguments: same as above, but the user sets the DUP flag. Cons: the user has to actually do know about this even if they just want to send QoS0 or don't care about retransmissions. Seems more complicated to me, for the same reason. It is quite prone to user errors

For the reasons above, I though hiding that "lovely" id in options was simpler and didn't break the current API
If we are going to break the API, then

QoS0+ with no interest in retransmissions:
mg_mqtt_pub(..., NULL);
QoS1+ with retransmission capabilities:
uint16_t id=0;
mg_mqtt_pub(..., &id);  // regular send, fills 'id'
mg_mqtt_pub(..., &id);  // retransmission, sets DUP flag and uses 'id'

id = 0 is invalid in the protocol, so it is a valid sign that we are sending a brand new message.

[scaprile]

BTW, our customer opening the issue likes this hidden logic #2689 (comment)