BUG/MEDIUM: peers: do not keep a dict entry cached when its update was not sent

BUG/MEDIUM: peers: do not keep a dict entry cached when its update was not sent

When an update message carries a server_key which is not yet in the peer's
dictionary TX cache, peer_prepare_updatemsg() inserts it into the cache and
encodes the full value. But if the message does not fit in the applet's
output buffer, applet_putblk() returns -1 and the message is simply dropped,
to be built again on the next call since last_pushed was not advanced. At
this point the entry is found in the TX cache, so only its ID is emitted,
and the remote peer, which never received the value, resolves this ID to a
NULL (or stale) entry in its RX cache. The server_key of this entry is then
lost on the remote side, as well as for all subsequent updates referencing
the same server for the whole session's lifetime, or it may even point to
another server whose value previously occupied the same slot.

This is easily observed during a resync of a table storing server_key with a
few servers having long names: the first update carrying a new server name
that does not fit in the buffer is retried without its value. With a debug
print on the receiver, ~100 entries out of 400 were received with an unknown
dict ID in such a test.

Let's record the node newly inserted in the TX cache in the update params,
and remove it from the cache when the message could not be emitted, so that
the next attempt sends the full value again.

The issue exists since the dict cache was introduced in 2.0 with commit
8d78fa7de ("MINOR: peers: Make peers protocol support new "server_name" data
type."), so this should be backported to all supported versions.