[dpazj]

Summary

Fixes the Edge Node session termination path so it no longer sends DATA after NDEATH and no longer sends a normal MQTT 5 DISCONNECT when the client can let the broker publish the Last Will.

• Add Client::disconnect_with_will(). The default returns false, so existing client implementations keep the current behaviour.
• Implement it for srad-client-rumqtt: it returns true without sending a DISCONNECT packet, so dropping the event loop closes the connection and the broker publishes the will.
• In NodeHandle::cancel, stop accepting data publishes, publish the NDEATH explicitly, and skip client.disconnect() when the client handled the will path.
• Add regression tests for the capability and the shutdown behaviour.

Why

edge:SessionTerminationTest failed with:

payloads-ndeath-will-message-publisher-disconnect-mqtt50

because rumqttc always sends NormalDisconnection (0.24, 0.25 and master hardcode it), and srad used a normal disconnect. The test also exposed a race: with the connection kept open briefly during shutdown, the data loop published NDATA after NDEATH, which the TCK monitor reports as an out-of-order sequence number.

Result

edge:SessionTerminationTest   PASS   35 assertions: 25 passed, 10 not executed
edge:SendDataTest             PASS   40 passed, 4 not executed
edge:SendComplexDataTest      PASS   48/48

The MQTT 5 disconnect-reason assertion is now NOT EXECUTED rather than FAIL. cargo fmt --all --check, cargo clippy --all-targets -- -D warnings and cargo test pass.

Trade-offs

• rumqttc cannot send MQTT 5 Disconnect with Will Message (0x04), so this closes the connection without a DISCONNECT. The assertion stays unexecuted until rumqttc exposes reason codes; there is a TODO in the rumqtt client.
• The NDEATH is still published explicitly because brokers (including HiveMQ) do not expose server-published wills to extensions, so the TCK and some subscribers would not see a will-only death. The broker will also publish the registered will, so subscribers receive the death certificate twice. This is unavoidable without protocol-level reason-code support and an extension API that surfaces wills.