- registry: make --dh mandatory
- node: retry if the registry returns nothing (instead of writing an empty file)

I forgot the case where 'config' has slightly different schema.
Now, we don't have any old network left to upgrade.

When 10.42.3.1/24 was configured on 'lo', the kernel accepted packets to
any ip of 10.42.3.0/24, instead of only 10.42.3.1

The old distutils way is not compatible with zc.recipe.egg in develop mode,
because egg_info does not provide any information about such scripts.

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 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.

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.