feat(mqtt): add Mqtt5ConnectionPropertyConfig — expose MQTT 5.0 CONNECT properties via MqttClientConfiguration

[daniil4udo]

Submission Checklist 📝

• I have updated existing examples or added new ones (if applicable).
• I have used cargo fmt command to ensure that all changed code is formatted correctly.
• I have used cargo clippy command to ensure that all changed code passes latest Clippy nightly lints.
• My changes were added to the CHANGELOG.md in the proper section.

Pull Request Details 📖

Adds MQTT 5.0 CONNECT-property support to EspMqttClient, the type-safe Rust wrapper around the ESP-IDF MQTT component.

The underlying C function esp_mqtt5_client_set_connect_property() cannot safely be called from user code after EspMqttClient::new() returns: by then mqtt_task is running and holds MQTT_API_LOCK across esp_transport_connect(), so the call deadlocks. The only safe window is between esp_mqtt_client_ini() and esp_mqtt_client_start(), which the wrapper now does internally.

Description

• Adds MqttProtocolVersion::V5 (gated on CONFIG_MQTT_PROTOCOL_5=y), required to negotiate MQTT 5.0 on the wire. MqttProtocolVersion is marked #[non_exhaustive] so future variants do not break downstream match arms.
• Adds Mqtt5ConnectionPropertyConfig, exposing the CONNECT-time properties: session_expiry_interval, will_delay_interval, receive_maximum, maximum_packet_size, topic_alias_maximum, request_response_info, request_problem_info, message_expiry_interval, payload_format_indicator. Each field is Option<T>; None leaves the property unset so the broker applies the MQTT 5 protocol default (the ESP-IDF encoder skips zero-valued fields).
• Adds mqtt5_connection_property: Option on MqttClientConfiguration, applied inside the wrapper in the safe init/start window.
• Returns Err(ESP_ERR_INVALID_ARG) (with an error! log line for discoverability) if mqtt5_connection_property is set without protocol_version: Some(MqttProtocolVersion::V5), replacing the opaque ESP_FAIL the C setter would otherwise return.
• Enables CONFIG_MQTT_PROTOCOL_5=y in the CI sdkconfig.defaults so the new #[cfg(esp_idf_mqtt_protocol_5)] paths are compile-checked across the build matrix.

All new types and fields are gated on #[cfg(esp_idf_mqtt_protocol_5)], so downstream crates that don't enable MQTT 5 in their
own sdkconfig see no API surface change. The MqttProtocolVersion enum gets #[non_exhaustive] as a one-time defensive addition;
the existing V3_1 and V3_1_1 variants are unchanged on the wire.

Usage:

MqttClientConfiguration {
    protocol_version: Some(MqttProtocolVersion::V5),
    mqtt5_connection_property: Some(Mqtt5ConnectionPropertyConfig {
        session_expiry_interval: Some(60),
        ..Default::default()
    }),
    ..Default::default()
}

Testing

Tested on ESP32-S3 hardware:

• Built with CONFIG_MQTT_PROTOCOL_5=y and protocol_version: Some(MqttProtocolVersion::V5), set session_expiry_interval and receive_maximum, confirmed via broker logs that the values appear in the CONNECT packet.
• Built with the default sdkconfig (MQTT 5 disabled), confirmed the new types are not present in the API surface and existing MQTT 3.1.1 code paths compile and run unchanged.
• Confirmed the pre-flight check: setting mqtt5_connection_property without MqttProtocolVersion::V5 returns ESP_ERR_INVALID_ARG (with a log line) instead of hanging on MQTT_API_LOCK or returning opaque ESP_FAIL.
• cargo fmt and cargo clippy clean on the changed code.

[ivmarkov]

@daniil4udo Looking at the PR details, it seems to contribute MQTT 5.0 support to the EspMqttClient type safe Rust wrapper of the ESP-IDF MQTT component.

However, rather than having a description along those lines, the current description of this PR contains some LLM gibberish which seems to be the last thing it did produce while implementing the MQTT 5.0 support.

Therefore, could you please restore the original PR template (the one available when opening a new PR) and try to fill it in (or let your LLM fill it in). This template is in there for a good reason. Amongst other things, it has a set of check-points you need to do for your PR to be ready for merge.

[daniil4udo]

@ivmarkov thank you for the feedback, fix it.
Beside the standard checks also ran it against real hardware in the personal project to check.

[ivmarkov]

@copilot resolve the merge conflicts in this pull request

[ivmarkov]

@ivmarkov thank you for the feedback, fix it. Beside the standard checks also ran it against real hardware in the personal project to check.

Right, I completely managed to forget about this PR :-(

Anyways. I think it is genuinely useful. what it is missing a bit is the MQTT5's support for user-define connection properties, but I guess even without it, it is good for merging.

Thanks a lot!