2.2.x branch has a patch[1] that renders tls_serial_* environment variables
in base 16, causing a ValueError exception in ovpn-server hook.

[1] https://github.com/OpenVPN/openvpn/commit/7d5e26cbb53e2700c966e6b6e815f0c824da8956

It doesn't matter anymore if there are many off nodes, because the registry
only queries the addresses of nodes that are in the routing table.

This does not increase of any packet because the size of certificate signature
only depends on the size of the certificate key.

With 512-bit hashes, it's still possible to use RSA keys as small as 768 bits.

There is no plan for a default ipv4 route.

This is useful because the default one is not always the same as the route
to the registry.

Before, arrows were filled dot. Now only the default one is filled.

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