If too many nodes create client tunnels without serving any, working servers
saturate and the network collapses.

Some routers are so broken that UPnP NAT don't report ConflictInMappingEntry
when redirecting the same port several times.

Here is for example what we had with a Numericable Box (France):

0 (1024, 'TCP', ('192.168.0.29', 1194), 're6stnet openvpn server (1194/tcp)', '1', '', 0)
1 (1024, 'TCP', ('192.168.0.16', 1194), 're6stnet openvpn server (1194/tcp)', '1', '', 0)
2 (1024, 'TCP', ('192.168.0.33', 1194), 're6stnet openvpn server (1194/tcp)', '1', '', 0)
3 (1024, 'TCP', ('192.168.0.20', 1194), 're6stnet openvpn server (1194/tcp)', '1', '', 0)
('192.168.0.29', 1194, 're6stnet openvpn server (1194/tcp)', True, 0)

Obviously, this can't work.

It seems that this router also accepts a limited number of NAT rules, far less
than we'd like, so even if there's still a probability of conflict with this
commit, it will be good enough for our use.

ENETUNREACH is the only error I've ever seen since the beginning of the project.

The main reason is to speed up recovery from temporary network cut:
- by not wasting time trying remaining distant peers that were collected during
  the last read of the routing table.
- by not blacklisting good peers, which would happen if too many of them were
  retried before network is back

For consistency with other log messages.

To be consistent with re6stnet.service

babeld could be in bad state, or it could be incompatible (too old or too new).

- getBootstrapPeer was stuck as long as there was no other request being served
- registry crashed when re6stnet is stopped

Code 4 was reused by mistake for 'kill' messages.

Co-authored-by: Julien Muchembled <jm@nexedi.com>

Here, it's simpler and safer. We will also want to have private methods that
don't start with an underscore.

Certificates are deleted 30 days after they get invalid,
so that unused prefixes can be reallocated.

This fixes the following error:

  TypeError: unsupported operand type(s) for -: 'NoneType' and 'int'
  Traceback (most recent call last):
    File "/usr/sbin/re6stnet", line 438, in main
      tunnel_manager.handleTunnelEvent(read_pipe.readline())
    File "/usr/lib/python2.7/dist-packages/re6st/tunnel.py", line 389, in handleTunnelEvent
      m(*args)
    File "/usr/lib/python2.7/dist-packages/re6st/tunnel.py", line 412, in _ovpn_route_up
      self._connection_dict[prefix].connected()
    File "/usr/lib/python2.7/dist-packages/re6st/tunnel.py", line 76, in connected
      i = self._retry - 1

What happened is probably that a route_up notification was received just before
killing/recreating the connection for the same node, and then process twice
the same OpenVPN notification: in this case, the first was for a previous
connection and should have been ignored.

We'll have to revive UDP because we experienced congestion with TCP.
This should make UDP efficient in good environment.
MTU discovery is required however to enable UDP by default.