fix: remove peer routing search-for-self

[achingbrain]

The peer routing module starts a recurring process that searches for
peers close to our peer id.

This makes the DHT module query the network for peers. Thing is the
DHT module is already doing this because periodically searching for
peers close to us is in the DHT spec so this ends up making redundant
queries.

This PR removes the recurring task configured by the peer routing module.

[vasco-santos]

What about a libp2p configuration with the delegates only?

[achingbrain]

Why would a client need to tell a delegate node to to query for themselves? They'd be doing that in the background to keep their routing tables up to date anyway, right?

[vasco-santos]

We use this to find and add peers to our PeerStore (and potentially connect with them), as part of the bootstrap process. These can include relevant peers like relays to use as auto relay nodes, as well as peers to fill in the pubsub mesh.

A follow up of this measure, would be to at some point drop connections with bootstrap peers when the peer balances its connections and figures out what are the most valuable peers to connect #744

[vasco-santos]

More information on the reasoning in #704

[achingbrain]

So I guess we either

a - exclude the DHT from the peer routing search-for-self timer
b - disable search for self in the DHT by default
c - make the dht delegate module support the same semantics as the dht spec and query for it's own peer id occasionally

a) breaks the PeerRoutingModule abstraction while b) seems like we are managing ambient peer discovery at the wrong level. c) adds another timer, though I guess you'd be unlikely to run the dht module and the delegate at the same time?

[achingbrain]

You could even merge libp2p-delegated-content-routing and libp2p-delegated-peer-routing to create libp2p-delegated-dht?

[achingbrain]

Option a: #1055