Improve the providing subsystem in Kubo

Kubo can reliably provide data to the Amino DHT.

ETA

Q2

Expected impact

Note: Targets kubo, the most widely used IPFS implementation and in practice the only one used by non-Filecoin SPs or pinning services to host content.

1. There should be no more issues where finding content ever takes more than 5s. When this happens today it is because data is not advertised into a mainnet content routing system by those hosting it resulting in kubo doing effectively a “random walk” until it finds them.
   This should not require high resource usage unless it’s needed (i.e. there is genuinely lots of data to advertise)
2. Instead of today when users don’t know when their content is available / ready (unless they’ve tested a particular CID) the tooling should be present for them to monitor “readiness” state as is possible with other servers (e.g. HTTP servers waiting for TLS certificates)
3. It should be possible to reduce (or prioritize) better how data is advertised (e.g. advertising CIDs for the middles of tar.gz files is of no use in almost all cases)
4. It should be possible for kubo to leverage different routing systems instead of being particularly coupled to Amino DHT semantics to enable future protocol evolution

Notes

• Need to capture some data points to quantify the impact that this change (reprovides sweep PR in Kubo) results in, and gauge if the PR's we have now are sufficient or not