peer address evitction

[jbenet]

currently we store a peer's addresses indefinitely. As of peer-restrict the peerstore will track these addresses, so it will be easier. Make sure everything uses the peerstore for its view on a peer's addresses (routing adds addresses to the peerstore directly. Then we can figure out how to determine a peer's addresses are stale.

This raises a larger question of address staleness on the routing system. Currently, provider records stored on the dht have a peer's address, which is a huge optimization that reduces query RTT count. This might need to be relaxed in the future to either:

• return those addresses with a measure of staleness (when it was received)
• prune out stale addresses. the requestor can fall back to FindPeer.
  (i'm reminded of skype's use of centralized trackers to find everyone, which greatly simplifies the problem, but we can't do in the long run).

This -- along with the notion of IPNS record validity -- makes me think the routing system in general should use validity for all its records (names, providers, peer info). So perhaps this problem can be greatly simplified by forcing that all values put carry a validity. Provider records and Address records need not share the same validity time. And nodes can then simply return any valid address records for GetProviders queries they receive (this is the exact analogue of a DNS glue record).

[jbenet]

This contributes to #573

[jbenet]

Related #603

[jbenet]

The addr explosion has been mitigated by:

• removing incorrect AddAddresses(.)
• peers now only take observed addrs which match a listen port (was incorrect before)
• introduction of https://github.com/jbenet/go-reuseport which substantially reduces the addresses peers see.

The larger problem will be addressed in #603