This simplify network configuration a lot, and on recent kernels, this fixes
wrong source address for extra interfaces that already have a public IP.

Generating them takes a lot of time and there's no reason to do this by default.
We keep --dh option in 're6stnet' to not break existing configuration.

We consider using sockets to communicate with OpenVPN, via --management option.

db.py -> cache.py
PeerDB -> Cache
peers.db -> cache.db

And automatic renewal of existing certificates.

For the registry at least, we'll want to store integers
without having to convert to/from strings.

To upgrade 'registry.db':
- dump it to a file
- fix create table statements
- load it

Nodes will restart with an empty cache.

These modes are partly unified with the normal one by splitting TunnelManager.

Also:
- use '/usr/bin/env python' to easily use a Python interpreter different than
  /usr/bin/python
- demo must be run by root so "dont_write_bytecode" to avoid having *.pyc files
  owned by root in the working copy

This is then easier to restart it manually.

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