improvement(peerTracker): peerTracker hardening

[vgonkivs]

The current implementation of peerTracker has some edge cases that I'd like to bring to your attention. Additionally, I'd like to propose some ideas I have.

1. As @renaynay mentioned p2p/peer_tracker: peerTracker scoring may be too aggressive #130 our scoring system is too aggressive. I believe, in the scope of this task, we should create an XLS table with different arithmetic methods (like EWMA) and then decide on the approach to adopt.
2. The second idea relates to collecting a specific number, 'n', of peers, calculating their rate, and building a queue from them. All peers are stored in the PeerStore, and we also have a libp2p component managing connections with these peers. Instead of redundantly collecting peers in the peer tracker, could we retrieve them from the peerStore? Also, rather than storing scores within the peer tracker, could we store them within the connection manager under a specific tag?

The proposed flow for the session would be:

Retrieve peers from the peer store.
Gather peer scores from the connection manager and build the queue.
Update the tag with the new respective value after the request finishes.

The primary advantage here is that by utilizing the connection manager, we can remove our custom gc and can handle garbage collection of slow connections and manage peer trimming.

[vgonkivs]

closed in favour of #160