Add MQTT 5 Support

[danielmeza]

Motivations

Checking the current supported MQTT protocol version we only enable the v3.* ones.
Would be great to include support for MQTT v5.

• Would you like to implement this feature? [y]

Is there any specific reason or consideration on why is not enabled?

[danielmeza]

Status update, with the specification references the design rests on.

References are to MQTT Version 5.0, OASIS Standard, 07 March 2019; each link below is a section anchor in that published HTML.

What the specification requires

MQTT 5.0 carries these properties in the Variable Header of the individual packet, not in connection state:

• §3.3.2.3 PUBLISH Properties
• §3.8.2.1 SUBSCRIBE Properties
• §3.10.2.1 UNSUBSCRIBE Properties

Only §3.1.2.11 CONNECT Properties are connection-scoped; those are already covered by MqttClientConfiguration::mqtt5_connection_property (#659).

Three properties make the packet scope explicit:

• §3.3.2.3.4 Topic Alias — "It is a Protocol Error to include the Topic Alias value more than once."
• §3.3.2.3.3 Message Expiry Interval — "If present, the Four Byte value is the lifetime of the Application Message in seconds."
• §3.3.2.3.7 User Property — "The Server MUST send all User Properties unaltered in a PUBLISH packet when forwarding the Application Message to a Client [MQTT-3.3.2-17]."

The same holds for the subscription side: §3.8.2.1.3 and §3.10.2.1.2.

A client-scoped setter therefore cannot express any of these correctly: two tasks publishing concurrently cannot carry different properties, and the value on the wire depends on the interleaving between the set call and the publish call.

Open work, in dependency order

1. feat(mqtt5): add per-message publish/subscribe/unsubscribe property APIs (IDFGH-18158) espressif/esp-mqtt#343 — adds esp_mqtt_client_publish5 / enqueue5 / subscribe5 / unsubscribe5, which take the property config for the message being sent and merge it over the client-level base inside the existing API lock.
2. Mqtt protocol v5 definition (rebased onto 0.29 + per-message properties) embedded-svc#87 — the client5 traits and the mqtt_protocol_v5 feature (supersedes Mqtt protocol v5 definition embedded-svc#84, which was rebased onto embedded-svc 0.29).
3. feat(mqtt): add MQTT v5 client5 module with per-message properties #678 — EspMqtt5Client / EspMqtt5Connection on top of both, behind an opt-in mqtt_protocol_v5 feature and CONFIG_MQTT_PROTOCOL_5=y.

#678 CI is currently red for exactly one reason: cargo validates dep/feature references even when the feature is not activated, so embedded-svc/mqtt_protocol_v5 cannot resolve until (2) is on embedded-svc master. embedded-svc has been added to the repo's existing [patch.crates-io] table (alongside esp-idf-sys and esp-idf-hal), so the run turns green the moment (2) merges, with no further change.