Add active peer probing and reputation caching

[lidel]

Someguy should be able to cache (#25) peerbook info returned on /routing/v1/providers, and build reputation over time for returned PeerIDs.

Goals

• P1: active probing of discovered peers
  • run libp2p identify in the background, cache results in peerbook for more than 48, e.g. 72h, remove need for client to probe PeerIDs to learn multiaddrs and supported protocols
• P1: return more stable / online PeerIDs first, and ones that have multiaddrs cached most recently
• P1: prioritize peers useful in browser context (/wss, /tls/../ws|http, /https, /webrtc*, /webtransport)
• P1: confirm when /tls/../http and /https is a trustless gateway, and add transport-ipfs-gateway-http to Protocols list in respective peer
• P2: build "badlist" and skip peers with well-known-deprecated transports, for example:
  • ipfs id --peerid-base base36 QmbNSJi9X4Phf5G6YgmVYWZiCzraLp5Ta4GT2XYHPwzE5S produces
    [/ip4/3.75.101.246/udp/4001/quic] QUIC draft-29 has been removed, QUIC (RFC 9000) is accessible with /quic-v1 and [/ip4/3.75.101.246/tcp/4001] failed to negotiate security protocol: read tcp4 192.168.50.102:4001

Implementation ideas

I imagine we could start with something built on top of peerbook system where every PeerID has additional attributes:

• last time PeerID was returned with /routing/v1/ response
  • allows us to do cache eviction of no longer relevant PeerIDs
• how many times PeerID was returned with /routing/v1/response
  • allows us to identify peers more important than others, because their presence impacts more users
• last time PeerID was probed / last time PeerID was seen online
  • allows us to prioritize peers which are online and useful due to their transport and protocols

Active probing could be async, going over peers with last time PeerID was seen online older than N (6?) hours and trying to connect to them and

• run identify, if libp2p multiaddr is present
• run trustless gateway probe, if potential HTTP endpoint is present

[2color]

Adding some notes from a call with @lidel:

• Explore using https://github.com/hashicorp/golang-lru/blob/main/2q.go for both recency and frequency cache of peer records
• Listen to identify events from the libp2p event bus to update the cache https://github.com/libp2p/go-libp2p/blob/cd88f9784044da5466534713a23d61d874774a53/p2p/protocol/identify/id.go#L167-L169
• Add an option in Boxo Handler to allow dependency injection of a cache (simple cache interface that is generic enough)
• instantiate the cache in someguy and pass as an option to the routing http server from boxo
• initially pick the cache size based on the number of DHT servers from probe lab
  • it's still random and arbitrary, but may be a useful starting point rather than something completely arbitrary
  • Later we can experiment with different cache sizes and monitor with prometheus metric for cache hits

[2color]

Closed by #90