MQTT 5.0: WillDelayInterval Will-property leaks into the delivered PUBLISH (#835) #1098

Summary

When a v5 client's Will Message is published, aedes leaks the WillDelayInterval
Will-property into the delivered PUBLISH packet. Will Delay Interval is a Will
Property (MQTT 5.0 §3.1.3.2) — it is not a valid PUBLISH property (the valid
set is in §3.3.2.3: Payload Format Indicator, Message Expiry Interval, Topic Alias,
Response Topic, Correlation Data, User Property, Subscription Identifier, Content
Type). Strict v5 clients reject the resulting PUBLISH:

Property WillDelayInterval does not apply to packet type Publish

This was surfaced by the new Paho interoperability workflow (#1094): the
test_will_message / test_will_delay cases fail against aedes but pass against
the Eclipse Paho reference broker under the identical harness — so it is a genuine
interop bug, not a harness artifact.

This contradicts the tracking issue #821, which currently marks #835 Will
delay as ✅ implemented & conformant.

Root cause

The will packet is stored with its full CONNECT Will Properties (which legitimately
include willDelayInterval). At publish time the delay value is read off the
will, but the will object — still carrying properties.willDelayInterval — is then
published as-is:

• lib/client.js:466-471 — reads will.properties?.willDelayInterval to schedule
  the delay, then passes the same will object to scheduleWill / publishWill.
• aedes.js:449-454 — publishWill calls this.publish(will, client, …), which
  serialises will.properties verbatim onto the outbound PUBLISH, including the
  invalid willDelayInterval.

Will Delay Interval governs when the will is published; it must be dropped from
the message that is actually published. The other Will Properties (Payload Format
Indicator, Message Expiry Interval, Content Type, Response Topic, Correlation Data,
User Property) do map to PUBLISH properties and must be preserved.

Fix

Strip willDelayInterval from the will's properties before it is handed to the
publish path (in publishWill, or once when the delay is consumed in
lib/client.js), leaving the remaining Will Properties intact. Guard for version === 5 / properties presence.

Reproduction

# from this repo, with the Paho suite cloned (see tools/mqtt-compat/README.md)
MQTT_PORT=1883 node tools/mqtt-compat/broker.js &
python3 tools/mqtt-compat/run_compat.py \
  --paho /path/to/paho.mqtt.testing/interoperability \
  --host localhost --port 1883 --protocols v5
# => test_will_message / test_will_delay fail with the WillDelayInterval error

Follow-up

Once fixed, downgrade the EXPECTED-vs-real classification is not needed (it is
already counted as a real failure, not an expected gap), and the
test_will_message / test_will_delay cases should flip to pass in the #1094
report. Update the #835 row in #821 from ✅ back to 🟡 until then.

Found via the MQTT compatibility workflow added in #1094 (part of #821).