fix(kad-dht): prefer connected peers to reduce unnecessary dials

[paschal533]

Summary

Reduces unnecessary new dials in the Amino DHT by preferring already-connected peers at three levels:

Tier 1 Query manager: connected-peers-first path distribution (query/manager.ts)

Before distributing the K closest routing-table peers into D disjoint query paths, sort them so already-connected peers come first. With a round-robin bucket assignment, each path gets a connected peer as its starting point, reducing the cold-dial penalty at the beginning of every DHT query.

Tier 2 Content routing: connected-peers-first ADD_PROVIDER fan-out (content-routing/index.ts)

After collecting the K closest FINAL_PEER events during provide(), sort them by connection status before enqueuing the parallel ADD_PROVIDER sends. The first ALPHA queue slots go to already-connected peers, so provider records reach the network with fewer new dials.

Tier 3 Reprovider: Kademlia key order sweep (reprovider.ts)

Port go-libp2p's SweepingProvider optimisation. processRecords now collects all CIDs that need reproviding, computes their Kademlia keys, sorts them lexicographically, and queues reprovides in that order. XOR-adjacent CIDs share the same K closest peers, so connections opened for one CID are reused for the next, reducing the total number of new dials across a reprovide run.

Test plan

• query.spec.ts verifies each disjoint path gets at least one connected starting peer when connected peers are available
• content-routing.spec.ts verifies connectionManager.getConnections is called during provide() for the connected-first sort
• reprovider.spec.ts inserts 5 CIDs in reverse Kademlia key order, then verifies contentRouting.provide is called in ascending Kademlia key order
• All 152 existing tests continue to pass
• Lint and TypeScript build clean

[achingbrain]

each path gets a connected peer as its starting point, reducing the cold-dial penalty at the beginning of every DHT query.

If the connected peer directs you to a closer peer that you already knew about (but were not connected to), this will make the queries slower since you have to wait for that confirmation before performing the cold dial.

It also gives the remote peer the chance to send you on a merry goose chase to peers that aren't as close as ones you already have in your peer store that you aren't connected to so may result in more unnecessary dials, not fewer.

After collecting the K closest FINAL_PEER events during provide(), sort them by connection status before enqueuing the parallel ADD_PROVIDER sends.

If you still have to wait for all K ADD_PROVIDER requests to complete for the operation to be a success, the order in which they are performed seems unimportant? Also you will probably be connected to them already since they should have responded in the affirmative that they don't know of any peers closer than they are?

Port go-libp2p's libp2p/go-libp2p#2774 optimisation.

This is great and needs to be done! Could be in its own PR though.

[paschal533]

each path gets a connected peer as its starting point, reducing the cold-dial penalty at the beginning of every DHT query.

If the connected peer directs you to a closer peer that you already knew about (but were not connected to), this will make the queries slower since you have to wait for that confirmation before performing the cold dial.

It also gives the remote peer the chance to send you on a merry goose chase to peers that aren't as close as ones you already have in your peer store that you aren't connected to so may result in more unnecessary dials, not fewer.

After collecting the K closest FINAL_PEER events during provide(), sort them by connection status before enqueuing the parallel ADD_PROVIDER sends.

If you still have to wait for all K ADD_PROVIDER requests to complete for the operation to be a success, the order in which they are performed seems unimportant? Also you will probably be connected to them already since they should have responded in the affirmative that they don't know of any peers closer than they are?

Port go-libp2p's libp2p/go-libp2p#2774 optimisation.

This is great and needs to be done! Could be in its own PR though.

This totally makes sense. I will close this PR now. (tier 3) is now in its own clean PR: #3426