Multiple CONNECT frames are sent during a reconnection.

This issue is related to #1098: The scenario is identical, with multiple MQTT clients in the same JVM. When the broker is restarted, the first client reconnects normally, while next clients initiate the TCP connection but do not send a CONNECT frame. After a waiting period, the broker closes these pending connections.

These clients then successfully reconnect:

- The client initiates the TCP connection and sends the CONNECT frame.
- The broker responds with the CONNACK frame, followed by a pending MQTT message.
- Unexpectedly, the client then sends a second CONNECT frame, which constitutes a protocol violation.
- The broker then closes the connection.

The next connection from these clients proceeds normally.

The Wireshark capture below highlights this behavior:

Note that CONNECT frames alternately specify the MQTT v3.1 (4) and MQTT v3.1.1 (5) protocol. If the protocol is explicitly set in the client, this behavior persists, but all CONNECT frames specify the same protocol.

Start by reproducing the broker-restart scenario with multiple MQTT clients and inspect the packet sequence in Wireshark. Trace the reconnect behavior until the cause of the second CONNECT after CONNACK is understood; done means reconnects no longer send duplicate CONNECT frames or trigger a protocol violation.

Written by the indexing model from the issue text.