feat: return target peer if we know about them

[Stebalien]

Previously, we'd only return the target peer if we were connected to them. However, this makes it difficult to impossible to find peers that are mostly disconnected from the network.

This change also changes p to from in several places as p is very confusing. We should probably switch away from using p everywhere.

[Stebalien]

So, there's actually a bit of an issue here:

The current FindPeer logic will try to dial this peer as part of the query. Unfortunately, this means we may try dialing this peer with cached & stale addresses. If we do that, we may end up backing off dialing this peer. Then, when we finish the query, we'll return all addresses for the target peer and the caller will try to re-dial this peer. The caller will fail because we're backing off.

Options:

1. Explicitly avoid dialing the target peer until we finish the query unless we encounter a peer that claims to be connected to the target peer.
2. Finish the back-off system (Add backoff system implementation go-libp2p-backoff#1).

cc @petar

[aschmahmann]

claims to be connected

We would need some way for a peer to make that claim, which involves some protocol change. We get some of this behavior if we have a separate field for returning peers that are not in our routing table. This would ensure that DHT nodes are on the "fast path" and other nodes are on the slower path of waiting for query completion before dialing (at least until the backoff improvements land).

Finish the back-off system

Surely the more correct option here.

[Stebalien]

We would need some way for a peer to make that claim, which involves some protocol change.

This is the "connectedness" field.

[Stebalien]

Ok, we've added better backoff logic to the swarm.