feat(kad-dht): findPeer

[richard-ramos]

Adds an utils function to find specific peers. Also does some filtering around the node's own peerId and append addresses to the peer store instead of replacing them

[github-actions]

🏁 Performance Summary

Commit: e8ec568df68fadb6e6c04642810a9f59211282ee

Scenario	Nodes	Total messages sent	Total messages received	Latency min (ms)	Latency max (ms)	Latency avg (ms)
Base test	10	100	900	0.301	2.359	0.986
Low Bandwidth rate 256kbit burst 8kbit limit 5000	10	100	900	0.249	78.031	10.824
Packet Reorder 15% 40% with 2ms delay	10	100	900	0.272	5.703	3.112
Queue Limit 5	10	100	900	0.310	2.466	1.066
Latency 100ms 20ms	10	100	900	20.358	229.198	109.869
Burst Loss 8% 30%	10	100	900	0.301	2.296	0.988
Duplication 2%	10	100	900	0.372	2.535	1.105
Corruption 0.5%	10	100	900	0.341	2.732	1.024
Packet Loss 5%	10	100	900	0.336	2.542	1.028
Combined Network Conditions	10	100	900	0.291	284.342	130.772

📊 View Latency History and full Container Resources in the Workflow Summary

[Ben-PH]

LGTM. just some things that you might like to change if they align with your style.

[Ben-PH]

Is there any reason to keep it in a seq instead of hash set? Wolud a BTreeMap/Set be appropriate? it's an ordered, sparse collection, but as discussed earlier, scaling isn't a concern: I'm more thinking that the nature of this collection is "indexible by key, sparse in nature, keys are inherently ordered" which fits the bill for a BTree of some sort quite nicely

[richard-ramos]

Not sure of the reason why the AddressBook uses a sequence to store its addresses instead of a different data structure. Sadly it's marked as {.public.} which makes refactoring harder as it's already part of the Public API

  AddressBook* {.public.} = ref object of SeqPeerBook[MultiAddress]