The way peer addresses were exchanged polluted caches with information about
dead nodes. In particular, bootstrapping often took a long time because the
cache of the primary node was mostly useless.

This also fixes bootstrap of registry.

Traceback (most recent call last):
  File "/opt/re6stnet/re6stnet", line 403, in main
    tunnel_manager.handlePeerEvent()
  File "/cygdrive/d/slapos/opt/git/re6stnet/re6st/tunnel.py", line 472, in handlePeerEvent
    self.sock.sendto('\1' + ''.join(msg), address)

This fixes a regression introduced with new protocol to registry (commit
e24eb3f5), which can't transport None value.

This is a common misconfiguration that may break internet acces for other peers.

We also stop checking for child process termination when used without tunnel
manager (i.e. with --client or --client-count=0) because it conflicts with the
'ip route' command that is called every minute if --table=0 is used.
Anyway, with a tunnel manager, only openvpn client are watched.

- authenticated communications with registered clients
- XML-RPC is dropped
- multi-threaded server

When a peer advertised several addresses, a node trying to create a tunnel to
it never tried any other address than the first one.

Before, we wrongly assumed OpenVPN would try all addresses before aborting
(--ping-exit). New code reexecutes OpenVPN until all addresses are tried
and update the peer db to reorder addresses if the first one failed.

'--ip any' was also broken due to missing parenthesis.

When 2 nodes were started for the first time whereas:
- one of them is in client-only mode, connected to the other one
- the registry node is temporarily down
then the normal node never tried to rebootstrap or connect directly to the
only node it knows (the registry node).
Such case required to restart the daemon when the registry is back.

Moreover, there was no reason to query the registry node immediately after
having open new tunnels to peers found in cache, when this number is less than
expected.

This reduces the probability to lose all connections at the same time when a
gateway becomes out-of-order.

This bug could even freeze re6st completely when trying to rejoin the network.

Non-numerical address should be rare and this could even be counter-productive:
such remotes are more likely to host other services and forcing routes may
break already opened non-re6st connections.