WIP: iterative find cleanup

[shyba]

This makes the iterative find algorithm behave mostly like described in the wiki, which looks in sync with how I found it described everywhere else so far.

Missing and some notes:

• add the stop condition in a way that is not too aggressive (tried as described, but it stops immediately)
  • the stop condition described in the wiki happens when the last element, sorted by distance, in list of nodes we have to return is closer to the key we are searching than the nodes we have available to query. The current issues trying to implement that are:
    • it is concurrent, so this can happen intermittently at many points in time, which makes it only feasible to do it on the _search_round which kind of has the whole context
    • stops too early when done there... which is weird (stops improving for real?)
    • when that happens, sometimes lowering alpha helps and increasing worsens it
• some kind of metric to see if we are improving or not, which I suppose could fit mainly 3 categories:
  • quality (average distance of returned nodes to key)
  • speed (time to find first value?)
  • traffic (crashing routers is no fun)
• feedback (later stage)

[coveralls]

Coverage remained the same at 69.641% when pulling 400c4e4 on iterative_find into 6343771 on master.

[lyoshenka]

• after Add prometheus metrics for DHT internals #3500 is merged, run master and this branch and compare which does better
• if its better, merge it
• Document current iterative find algo (release?) #3541 if this branch is not better