Protocol change: Initiate key setup on incoming packets, not outgoing ones

Protocol change: Initiate key setup on incoming packets, not outgoing ones

If data is exchanged after the "renegotiation time", we need to
refresh the data transfer key - ie, to initiate a key setup.
Previously this was done by the peer which wanted to transmit data
using an existing but in-need-of-refreshing key.

However, mobile peers may often be disconnected.  There is no point
trying to do a key renegotiation while they are disconnected.  Thus it
is better to have the renegotiation initiated by a peer which receives
a data packet.  That means that if there is a network outage,
renegotiation will be deferred until the network is restored.

In particular, it means that a mobile node which has no underlying
network but which has applications trying to send data will not waste
effort attempting key renegotiation until it once more has
connectivity.

This minor functional change should be harmless or even beneficial for
non-mobile sites too.  It simply means that the other peer will play
the role of initiator during renegotiation, but since which peer
played this role is arbitrary for non-mobile sites this should make no
difference.

Compatibility: In the case of an old version of secnet talking to a
new version, only data packets in one direction will cause
renegotiation.  This should not be a problem since all real-world
IP protocols involve data in both directions.

So we make the new behaviour universal rather than making it depend on
the forthcoming "mobile-peer" site config option.

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