Provide newly received blocks according to reprovide strategy

[guillaumemichel]

Checklist

• My issue is specific & actionable.
• I am not suggesting a protocol enhancement.
• I have searched on the issue tracker for my issue.

Description

Context

It seems that kubo/boxo is providing all newly received blocks to the DHT (source).

These blocks will not be reprovided if they don't match the reprovider strategy.

What was the rationale for this?

Proposed solutions

a) It seems reasonable to apply the reprovider strategy on newly received blocks as well. This would reduce the number of provides, and allow the (re)provider system to manage the reprovides by itself, independently from the blockstore.

b) If providing all newly received blocks is actually desirable, I suggest changing the provider interface to let the (re)provider system to provide the key once only (and not reprovide it).

Motivation

A change is required to allow the DHT SweepingReprovider to track which keys must be reprovided.

• Unified Provide Interface for Content Routers #10097
• feat: Reprovide Sweep libp2p/go-libp2p-kad-dht#1082
• feat: DHT Reprovide Sweep #10834

[hsanjuan]

Rationale was "people add things and they expect them to be available right away". Now things are enqueued in the reprovider which will do its thing when it does (before, they were provided directly).

Things are tricky so the current way is "let's enqueue everything once, then follow the strategy". In order to improve, we would need to potentially Provide() from places like the Pinner (when a new pin completes and Strategy == pinned) or MFS (when something is copied to it and strategy == mfs). etc. instead of centralizing on Exchange.

[lidel]

Triage notes:

• Right now Reprovider.Strategy is ignored by one-time Provider: Kubo provides all new blocks that appear in local blockstore
• We could find a way to make it work with existing codebase
  • keep things as-is if Reprovider.Strategy=all - provide every new block that arrives
  • disable providing triggered by Bitswap/Exchange if Strategy is different, and then do manual provide only if new blocks were created by a command that "falls under" strategy:
    • if Reprovider.Strategy=pinned do manual provide in commands that create pins ipfs add|pin add|dag import| etc commands
    • if Reprovider.Strategy=mfs do manual provide in commands that change MFS root
    • tricky part: how to produce set of cids to provide? (walk offline DAG before and after, and calculate delta of blocks that arrived due to specific command?)
• However, it may be more cost-effective to include this gap as design input for ongoing wider Reprovider refactor related to feat: DHT Reprovide Sweep #10834
  • @hsanjuan will research if it is feasible to do fix without waiting for the biggger refactor