fix: discard a connection whose reply was never read

[cconstab]

The problem

If a command is sent and its reply is not fully read — a read timeout, or any error raised while reading — that reply stays queued on the socket. Reusing the connection hands it to the next command, and every command after that is one reply behind. A lookup can then return a completely different record's value, with no error raised anywhere.

How it showed up

In a long-running deployment, publishing to one recipient began failing every cycle with:

Failed to decrypt shared_key.<recipient>@<sender>
  - Ciphertext length must be equal to key size.

The stored shared_key record was perfectly good. The lookup was returning the previous command's reply, which is not an RSA ciphertext. Restarting the process cleared it — the fault was in the connection, not the data.

Reproduced directly against a live atServer: after an abandoned read, llookup:publickey@bravo returned the earlier shared_key reply.

The fix

execute_command disconnects when a reply cannot be read, so the next use starts from a clean stream (disconnect() clears _connected, so connect() rebuilds — #523).

Deliberately minimal:

• the successful path is untouched — the new handling only wraps the read;
• commands sent with read_the_response=False (monitor, noop) are unaffected;
• it composes with the existing retry_on_exception branch, which calls connect() and will now get a fresh socket.

This matters more as callers adopt read timeouts (which are otherwise the right way to stop a silently dead peer blocking forever): without this, a timeout trades a hang for a connection that quietly returns wrong answers.

Tests

test/abandoned_read_test.py, network-free:

Case	Expected
read raises (timeout)	exception propagates and the connection is left unusable
read succeeds	response parsed, connection still usable
read_the_response=False	unaffected, connection still usable

Related

Supersedes #544, which I closed: I had misattributed this incident to a damaged shared_key record. Since the desynchronised case reports the identical error, replacing the key there would have rotated a perfectly good shared key for both parties — fixing the cause is both safer and sufficient.