Adapt metric to include the hop count of a route

[LeeSmet]

Currently the link cost of a peer is the time between the last Hello packet and a matching IHU packet. In other words, it is the latency (link + processing cost) to a peer. This link cost is added to the metric of some remote when advertising said remote to the peer. In addition to this, we add a static value to this computed link cost (which is also smoothed over some time), to signal that a hop is not free, and some processing of the packet takes place. The metric is in essence a sum of link costs of all used links in a packet's path. This makes intuitive sense.

While #75 will change the way the link cost is computed, it won't do so fundamentally. Link cost will still be a measure of latency on the actual connection. As a result, no significant change is expected to the metric value itself.

We actually could be interested in the amount of hops a packet must take, which is currently not expressed. Although the implementation of #12 allows us to use traceroute/tracepath to detect the peers in the shortest path, it requires some actual data to be send. Since a metric can express a latency of at most 65535, and it actually represents an expected packet rtt, we have some bits we could potentially use to encode the hop count of a path.

Specifically, if the top 4 bits are used to express a hop count, we can encode up to 15 hops, while maintaining up to 4096 ms of latency in the calculation. Furthermore, the requirement that metric is an increasing and ordered property remains, even in the u16 encoded variant. Since the top bytes are used to encode hop count, old nodes would always consider the path with the least nodes as the shortest. We also need to decide which component is not allowed to be maxed, as maxing both would lead to the restricted all 1 bit pattern.

We can't simply use hop count as metric for the shortest path, since not having a latency reference means a hop across the world would be considered as shorter than 2 link local hops. To this end, the hop count should only be a factor if the latency difference between 2 routes is sufficiently small.