Unstable latency

Opening an issue and sending a pull request to address (hopefully) at least part of it.

This is with regard to the jumpy latency observed by toyowheel et al. For anyone who's interested, the situation is basically as follows:

Before my previous PR (https://github.com/cjdelisle/cjdns/pull/363), paths were selected by the length of the nonempty part of their label. This occasionally causes the pathfinder to pick very, very stupid routes, but it's at least consistent about it.

After that PR, it's selected almost entirely by reach (with a small additive adjustment to let route selection still work for paths where reach isn't yet known). That results in unpredictable latency spikes, as the pathfinder changes its mind about which route to use. These generally smooth out after several seconds of continuously talking to a node, while the pathfinder probes (pings) other paths to measure reach, and finally settles on a good path to use. Unfortunately, the first few packets still suffer from higher latency, which may hurt load times and definitely hurts any sort of scheduled latency monitoring (where the routes are never used long enough for the pathfinder to accurately probe any routes).

This PR hopefully addresses at least part of that issue. Reach and label length are now both taken into account when selecting a path to use. This method was tested before, and showed to behave very slightly worse than the pure-reach method after all routes have had their reach measured. However, it should be less aggressive about transitioning between wildly different routes that happen to have about the same reach.

This is probably the right thing to do, even if it doesn't solve the latency spike issue. Somebody who's experiencing problems should test to see if / how-much this changes the situation, before I investigate further.