Async Refactor: random-walk

[kumavis]

switched over to a _running state var and and while(true) async loop instead of managing timeoutIds

skipped a test that was expecting queries to be run in series and that errors would stop the other queries. Should an error in _walk trigger randomWalk to stop? currently we log and ignore

updates #82

[dirkmc]

I don't think an error should cause random walk to stop - we don't really care about past errors for the purposes of random walk, we just want to walk the DHT to find new peers

[kumavis]

@dirkmc i skip()ed a test that expects an error to stop the query, do you think i should delete the test?

[dirkmc]

I would say we should have a test for the opposite case - that the random walk does continue even if there's an error, but I would like to hear from @vasco-santos and @jacobheun if they know of a reason why it was written this way originally.

[jacobheun]

I would say we should have a test for the opposite case - that the random walk does continue even if there's an error.

I agree, there's no reason to stop the random walk on an error. The only reason the walk should stop is if the query is done or it timed out.

[vasco-santos]

Agree that it should keep going!

[kumavis]

@vasco-santos @jacobheun ready to go

[kumavis]

fixed the conflict

[vasco-santos]

Thanks for another PR @kumavis

Just left a minor request

[kumavis]

@vasco-santos I'll handle the multihashing-async update in a separate PR, as it will affect more files than randomWalk

[dirkmc]

Should we be checking this._timeoutId has not been cleared after the walk has completed?

[vasco-santos]

That's a good point! We can check and not do the timeout if needed.