Better BEP51 sample_infohashes sharing strategy

[mordae]

Hi, I have noticed that you are selecting hashes for sample_infohashes replies randomly.

While this bootstraps other nodes fairly quickly initially, the rate of convergence would fall off as they keep seeing more and more duplicates they have already received. This could be countered by instead selecting hashes using a quasirandom sequence.

// Each node's own address to partition the space more effectively.
// IP use is optional, could be replaced with random number per-start.
// Just a [0, 1) float.
local_seed = hash_to_float(our_IP)

// For each peer IP we are responding to we hash and map to [0, 1) float.
peer_seed = hash_to_float(peer_IP)

// To step through the space at speed equal to rate at which we
// are actually sharing the keys.
step = floor(current_time / sampling_interval)

// Obtain final offset.
phi = 1.6180339887498948482
start = frac(local_seed + peer_seed + step / phi)

// Pick 20 consecutive items from the sorted set of hashes.
first_idx = floor(start * len(keys))
for i := 0; i < 20; i++ {
    idx = (first_idx + i) % len(keys)
    result[i] = keys[idx]
}

This guarantees that we will eventually send each peer full copy of our index with minimum duplicates. And if most participants share basically the same set of hashes, it minimizes number of duplicates transmitted globally.

It would require using an ordered set of hashes, though. A simple B-Tree would suffice.
On the other hand, it requires zero peer tracking -- it is entirely stateless.

(Above is basically R₁ -- Kronecker. We could do R₂ too, but above is somewhat easier to understand I believe.)

[mordae]

Oh, and I've just realized that if you instead convert that [0, 1) probe into a hash and share 20 following where it would land in the list, this will actually be globally consistent and yield even better coverage.