Broker compatibility: add option for brokers not 100% mqtt compliant

[GwendalRaoul]

Some brokers (like AWS iot core) do not support qos=2 or retain
messages.
Add option to transport to specify the max qos value to use and also
if the retain flag is supported by broker.

In case of retain flag, behavior of transport is a bit different.

[teemupiiroinenwirepas]

Does the code already check the message ids everywhere so e.g. remote api / OTAP commands are not sent twice to the network / node if sent with MQTT QoS1?

[GwendalRaoul]

Does the code already check the message ids everywhere so e.g. remote api / OTAP commands are not sent twice to the network / node if sent with MQTT QoS1?

No it doesn't. We could keep a table of cmd ids received. But I don't know what should be the time window to keep them. In case of Qos1, how long can be the delay between 2 duplicates?

[teemupiiroinenwirepas]

Does the code already check the message ids everywhere so e.g. remote api / OTAP commands are not sent twice to the network / node if sent with MQTT QoS1?

No it doesn't. We could keep a table of cmd ids received. But I don't know what should be the time window to keep them. In case of Qos1, how long can be the delay between 2 duplicates?

It is usually several minutes, as it happens only when there is high load. One easy solution would be just to keep the last id in the memory per message type and do the checking with it.