fix(kad-dht): getClosestPeers timeout

[dozyio]

Description

• Move routing-table updates off the getClosestPeers hot path so query progress/event streaming is not blocked.
• Centralise update scheduling in RoutingTable and use a dedicated PeerQueue with per-peer dedupe (find/join).
• Apply the same queued update path for topology-triggered updates (onPeerConnect).
• Add configurable queue concurrency via routingTableUpdateQueueConcurrency.
• Expose queue depth metrics via queue metric wiring for Grafana.
• Update getClosestPeers to yield query results directly (no peer filtering/mutation).
• Wire missing networkDialTimeout (thanks @paschal533).

Change checklist

• I have performed a self-review of my own code
• I have made corresponding changes to the documentation if necessary (this includes comments as well)
• I have added tests that prove my fix is effective or that my feature works

[dozyio]

@achingbrain any chance you could take a look at this one please?

[achingbrain]

A few notes:

• Maybe make the routing table .add method synchronous and encapsulate the update queuing logic inside the routing table class instead. The query manager seems like the wrong place to me.
• If you use the PeerQueue class from @libp2p/utils instead of the generic Queue it will deduplicate jobs based on the passed PeerId for you (call .find(peerId) on the queue and then .join(opts) on the job if present).
• Pass a metrics instance and metricName option to the Queue/PeerQueue constructor to have it show up in graphana (essential to tune parameters)
• You can continue to use a queue after .abort() is called on it, no need to have the queue field be Queue | undefined in the containing class - just create it in the constructor as normal
• Most of the routing table stats would be available to graphana via the built in metrics, it seems redundant to hold them in memory
• The routing table stats seem to be most useful for tests - consider using sinon spys instead
• There seems to be some duplicate logic around when to perform routing table updates - this is defined by the spec and the routing table already has an interval during which a peer will not be re-pinged
• "Routing" is an overloaded term in libp2p so the new config options should be fully qualified (e.g. routingTableUpdateQueueConcurrency)

[achingbrain]

Suggested change

These conditionals probably all need to go and any results found should just be yielded.

A peer can be returned from a query without multiaddrs. It's not invalid, it just means that their multiaddrs have expired in the peerstore of the node returning the peer.

From memory I think multiaddr expiration was added in js after this code was written though it was present in go which is why peers were returned without multiaddrs which looked like an error.

If the calling code wants to dial the peer, it should execute a findPeer query to get updated multiaddrs before dialling (the dial queue already does this here).

[achingbrain]

This is better, we should just yield the query result without modifying it.

[dozyio]

Thanks @achingbrain for the feedback - Hopefully addressed all the issues although I didn't make the routing table .add method synchronous - would require a fair amount of change as many of the internals are async.

Also reduced the scope a bit by removing the peer TTL stuff and custom queue metrics.

[achingbrain]

LGTM, tested locally & is much faster.

Couple of small comments inline.

[achingbrain]

The composite signal needs to be passed to the job.

Suggested change

	signal: options.signal
	signal

[achingbrain]

Should also allow configuring the maxSize parameter otherwise this can grow in an unbounded fashion.