feat: add delay support to random walk

[jacobheun]

resolves #100

This adds support for delay in the random walk config. This allows random walk to be run more quickly after startup, while maintaining a longer interval.

I ran this against js-ipfs master with a randomWalk config (all options aside from enabled are default):

randomWalk: {
  enabled: true,
  interval: 300e3,
  delay: 10e3,
  timeout: 10e3
}

With an idle node, I had 100+ connected peers in under a minute. The connected peers eventually stabilized around the max peers of ~300.

logging: I also updated the randomConfig logging to make it easier to target for debugging. Instead of DEBUG=libp2p:dht and sifting through the logs, you can now have DEBUG=libp2p:dht:random-walk* and follow only random walk logs, and error logs.

Note: libp2p fix libp2p/js-libp2p#359 will need to be released before delay can be configured by js-ipfs or other projects.

[dirkmc]

LGTM 👍

If random walk is stopped, it could take several minutes before the walk function actually stops, holding open the process. Is it worth refactoring so that random walk has access to the Query that findPeer() uses so that it can call query.stop()?

[vasco-santos]

LGTM 💪

[vasco-santos]

@dirkmc I agree that it would be great to add it, as the results obtained from an ongoing query will not be relevant. I think we can add it in a new PR, as this is looking good to go. What do you guys think?

[dirkmc]

Agreed - I'm fine with it being done in a new PR

[vasco-santos]

Created #102 for tracking that. It should be an easy addition to the random-walk codebase

[jacobheun]

Yes it's a good idea, and actually I think the existing randomWalk query logic is wrong right now. I'll look at a fix for it with the timeout update.