site: Send NAKs for undecryptable data packets (msg0)

Packets which are not understood are supposed in general to produce
NAKs, to let the peer know that we don't have the key they were using.

However, previously this would only happen if the incoming packet had
a local site index which was not in use.  But it can happen that a
particular index value is reused by a recently restarted secnet.
Previously, in this case, data packets would simply be thrown away
undecryptable.

With this change, undecryptable data packets always generate a NAK.
(But we don't generate a NAK if the packet was decryptable, but
suffered from sequence number skew - if we did, then network glitches
would trigger spurious key exchanges.)

This is particularly relevant for mobile sites, as it can happen that
the fixed site doesn't have an address for the mobile site - so the
association will remain stuck in a broken state until the mobile site
is also restarted.

There is still a potential problem when a site is restarted mid key
exchange.  The peer will refuse to start a new key exchange (because
of the retry timeout) and the restarted site may not know it's
necessary.  This will be dealt with in a later patch.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>