Connected notification handler races with identify protocol

[whyrusleeping]

As far as I can tell, identify and the dht 'check if this peer supports the dht protocol' happen concurrently. This doesnt bite us too bad, except for the fact that our 'happy path' for DHT peer detection relies on identify discovering protocols of the peers we talk to.

I noticed this when I was looking into using a peers reported listen addrs to determine if we should add them to our routing table.

We should probably use the event bus to signal 'identify complete' for peers, and have the DHT use that to find new peers to add to their table, instead of the connection notifications (i think this is the plan anyways, but just pointing it out)

[raulk]

Proposal:

1. Add an event EvtPeerIdentifyComplete, emitted by identify once identify succeeds. EvtPeerIdentifyFailed if it times out.
2. Have the DHT subscribe to those events.
3. Park routing table candidates in a temporary map.
4. When we receive EvtPeerIdentifyComplete, we evaluate inclusion in routing table as per don't add peers with only private addresses to your routing table #360.
5. When we receive EvtPeerIdentifyFailed, we remove the candidate from the parking area.

@magik6k fancy implementing the emitter side?

[whyrusleeping]

This means that we will be dropping our 'connected' notification handler

[raulk]

Fixed in #365. Will eventually be merged to master.