[Meta] MQTT 5 support development

[andsel]

This issue is a meta issue to track all the changes that needs to be done in order to support MQTT5 version of the protocol.

• Update the Netty to the latest to have full MQTT 5 version protocol support Update Netty from 4.1.77 to 4.1.85 #696

• Connection management

  • accepts a v5 connection message
    • avoid to resend PUBLISH and PUBREL with a timed handler, spec [MQTT-4.4.0-1]
      "When a Client reconnects with Clean Start set to 0 and a session is present, both the Client and Server MUST resend any unacknowledged PUBLISH packets (where QoS > 0) and PUBREL packets using their original Packet Identifiers. This is the only circumstance where a Client or Server is REQUIRED to resend messages. Clients and Servers MUST NOT resend messages at any other time." Avoid to pub retries on timeout #697
    • Reply to a connect with the capabilites offered (Retain Available, Maximum QoS, Server Keep Alive) in ConnACK properties. Feature/connack with capabilities #709
    • Reply with proper CONNACK reason strings and reason codes. CONNACK return also reason string #713
    • Switch from cleanSession to cleanStart flag and SessionExpiryInterval property Use session expiry from CONNECT message properties #753 and Uses the expiry interval from connect properties #764
  • Manage Will Delay Interval for MQTT5 #767
    The Server delays publishing the Client’s Will Message until the Will Delay Interval has passed
    or the Session ends, whichever happens first. If a new Network Connection to this Session
    is made before the Will Delay Interval has passed, the Server MUST NOT send the Will Message [MQTT-3.1.3-9].
  • Server can define its own Keep Alive in CONNACK #789
  • Assigned ClientID: In cases where the ClientID is assigned by the Server, return the assigned ClientID. This also lifts the restriction that Server assigned ClientIDs can only be used with Clean Session=1 connections.
  • Server reference: Allow the Server to specify an alternate Server to use on CONNACK or DISCONNECT. This can be used as a redirect or to do provisioning.
  • Maximum Packet Size: Allow the Client and Server to independently specify the maximum packet size they support. It is an error for the session partner to send a larger packet.

• Subscription

  • Shared Subscriptions: Add shared subscription support allowing for load balanced consumers of a subscription. [Meta] Implement Shared Subscriptions #791
  • Subscription ID: Allow a numeric subscription identifier to be specified on a SUBSCRIBE, and returned on the message when it is delivered. This allows the Client to determine which subscription or subscriptions caused the message to be delivered. Implement Subscription identifier #801
  • Subscription options: Provide subscription options primarily defined to allow for message bridge applications. These include an option to not send messages originating on this Client (noLocal), and options for handling retained messages on subscribe. Implements Subscription Options #808

• Various aspects

  • Message expiry: Allow an expiry interval to be set when a message is published. Implement message expiry intervals functionality #818
  • Payload format and content type #825
  • Request / Response: Formalize the request/response pattern within MQTT  #829
  • Flow control: Allow the Client and Server to independently specify the number of outstanding reliable messages (QoS>0) they allow. The sender pauses sending such messages to stay below this quota. This is used to limit the rate of reliable messages, and to limit how many are in flight at one time.
  • User properties: Add User Properties to most packets. User properties on PUBLISH are included with the message and are defined by the Client applications. The user properties on PUBLISH and Will Properties are forwarded by the Server to the receiver of the message. User properties on the CONNECT, SUBSCRIBE, and UNSUBSCRIBE packets are defined by the Server implementation. The user properties on CONNACK PUBACK, PUBREC, PUBREL, PUBCOMP, SUBACK, UNSUBACK and AUTH packets are defined by the sender, and are unique to the sender implementation. The meaning of user properties is not defined by MQTT.
  • Optional Server feature availability: Define a set of features which the Server does not allow and provide a mechanism for the Server to specify this to the Client. The features which can be specified in this way are: Maximum QoS, Retain Available, Wildcard Subscription Available, Subscription Identifier Available, and Shared Subscription Available. It is an error for the Client to use features that the Server has declared are not available.
  • Enhanced authentication: Provide a mechanism to enable challenge/response style authentication including mutual authentication. This allows SASL style authentication to be used if supported by both Client and Server, and includes the ability for a Client to re-authenticate within a connection.
  • Topic alias to define

---

Other secondary features

• provide a way to define (in config file maybe) the User properties to return with CONNACK.
• provide a way to define Server reference in CONNACK and DISCONNECT.

---

Useful refs

• Development branch: https://github.com/moquette-io/moquette/tree/main
• HiveMQ blog series: https://www.hivemq.com/tags/mqtt-5-essentials/
• Oasis specification: https://docs.oasis-open.org/mqtt/mqtt/v5.0/mqtt-v5.0.html
• Previous work: [WIP] implement MQTT5 connect logic #558

[andsel]

Thank's @hylkevds for crafting the list