QoS2 support for native MQTT

[tsigcn]

@michaelklishin

As mentioned in #11842, is it possible to develop function for MQTT QoS 2 first?
Anyway, AMQP and other protocols do not have the issue like "DISCONNECT with Reason Code 0x9B (QoS not supported) ".

We found there is a MQTT proxy sample which can receive QoS 2 messages and publish as QoS 1 message to RabbitMQ via AMQP.
https://github.com/grepplabs/mqtt-proxy
As known, RabbitMQ has native MQTT support, maybe it will be easier to implement with MQTT than entire RabbitMQ.

[michaelklishin]

@tsigcn I don't have anything to add to what I've said #11842:

We will not make any promises as to when or if QoS 2 may land in RabbitMQ. Like I said, QoS 1 is perfectly sufficient as far as data safety goes. QoS 2 does not deliver any meaningful safety improvements but takes months of effort to implement for a small team like ours.

Other protocols RabbitMQ supports do not have a direct QoS 2 equivalent and their users are perfectly fine because they do provide a confirmation mechanism not meaningfully different from QoS 1 in MQTT.

It may be added one day for cases such as this one but I though I have made it very clear that this is not a trivial time investment for a small team like ours, and we absolutely cannot make any public promises.

[michaelklishin]

@tsigcn please stop bringing up this topic or trying to convince our team that "QoS 2 is easy to add to just MQTT" or you will be barred from ever starting a discussion in any of this org's repos.

Our team has evaluated the feasibility of adding support for QoS 2. Like I said, it would take a non-trivial amount of time (several person-months) to add, and this is not a priority for RabbitMQ 4.0 and likely 4.1. In any case, we are employed by a publicly traded company and cannot make any promises of feature delivery.

AMQP 1.0, AMQP 0-9-1, STOMP and RabbitMQ Stream Protocol do not have a QoS 2 equivalent, and are successfully used at massive scale. It has been the case for years.