Don't connect() to the server as a client

If the client connect()s to the server, the resulting UDP socket looks
like this in netstat output:

udp        0      0 192.168.11.11:44629     144.XX.YY.ZZZ:7878 ESTABLISHED 19068/tappet

Now if the client's IP address changes, writes to the socket begin to
return EINVAL. (But if the address changes back, the socket starts to
work again!)

On the other hand, if the client does not connect(), netstat shows this:

udp        0      0 0.0.0.0:51217           0.0.0.0:*                      19125/tappet

If the client's address changes, writes to the UDP socket continue to
work, and all is well. So it's clearly desirable to not connect() to
support operation on dynamic endpoints.

But that means we need to be more careful about updating our idea of the
peer's address, since an unconnected socket will receive packets from
senders other than the server. So now we update the peer's address and
nonce only *after* we've verified that we received a correctly-encrypted
packet. This new logic is better independent of the changes above.
Send keepalives from the server too

There's no especially good reason to avoid sending them, and I'm working
my way slowly towards bind()ing to INADDR_ANY on the server, so that the
client can cope with a _server_ IP address change.

If that happened right now, I expect the server would also receive
EINVAL when it tried to write to the socket. It can't avoid bind()
altogether because it needs to set the port, but INADDR_ANY should
work fine.

Is it worth doing? It certainly won't receive much testing…
Revise the directions a little.