Improves peer priorization protocol

[litchipi]

Improvement of #4261

As we need to iter over all the peers before getting the priorisation result, it's inefficient and could lead to some problems when there are thousands of peers in question. (As this process is executed every 250ms)

On the original PR:

The measures for a given number of peers in the iteration:

1000:    ~ 3 ms
5000:    ~ 10.5 ms
10000:    ~ 17 ms
30000:    ~ 63 ms

An idea to improve this:

use a BTreeMap to store the peers using the metadata (ordered by prio) as indexes somehow, and then iter a single time over them to fill the connection slots