Leverage /https peers

[lidel]

This is a subset of #42 limited to leveraging content providers that announce /https and /http/tls multiaddrs.

How would this work?

Content providers with /https and /http/tls could work today. These are plain HTTP Gateways compatible with https://specs.ipfs.tech/http-gateways/trustless-gateway/ specification, require no libp2p, we could start prototyping with them for now

For example all CIDs hosted by https://nft.storage/ are provided at /dns4/dag.w3s.link/tcp/443/https. This provider multiaddress is returned for /routing/v1 query: https://cid.contact/routing/v1/providers/bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi

I think MVP here is that if ipfs-chromium is not able to fetch CID from the gateway pool it has, it fallbacks to finding providers via /routing/v1 endpoint(s).

How to test this?

For now, use local endpoint. After Kubo 0.23 ships it will be possible to prototype against local instance by setting Gateway.ExposeRoutingAPI to true (release notes)

Soon after, we want to expose it on https://ipfs.io/routing/v1 and we expect that over time, some other gateways will expose it as well, allowing for redundancy/fallback. This will remove ipfs.io as a single point of failure, and increase utility of gateways beyond content retrieval.