MQTT v5: QoS 2 support

[voycey]

Is your feature request related to a problem? Please describe.

Since the release of MQTTv5 support for RabbitMQ it has become a very clean way to implement a basic broker on top of an already well established piece of software. Gaining further support for the MQTTv5 standard and feature parity with the standard would offer an amazing alternative to the existing tools out there.
QoS2 (Exactly once delivery) is, in many applications a requirement.

Describe the solution you'd like

Implementation of QoS 2 per the standard:
https://docs.oasis-open.org/mqtt/mqtt/v5.0/os/mqtt-v5.0-os.html#_Toc3901237

Describe alternatives you've considered

No response

Additional context

I appreciate that this isn't as simple as just implementing it as there are likely considerations around how this interacts with the underlying queue system and that exactly-once delivery in a distributed system is a difficult problem, but I would like to open this as a sounding board for this feature to discuss the various methods as to how it could be implemented, even if that implementation isn't 100% in the core code (external state mechanisms?)

[michaelklishin]

QoS 2 offers no meaningful data safety improvements over QoS 1 and it is not a requirement for most systems. Plenty of distributed system algorithms, including those you rely on in RabbitMQ (with quorum queues, streams, Khepri) do not use this "N-phase commit" approach and somehow everyone is perfectly fine with that.

Implementing QoS 2 support is therefore mostly a matter of "checkbox-driven development."
This has been discussed as a 2024 roadmap item but we do not offer any delivery or ETA promises.