Provider interface

[guillaumemichel]

This PR is just a place to discuss the interface, it doesn't contain actual code.

DHT Provider Interface

Here is the suggested Provider interface for the SweepingReprovider, to be used in kubo to replace boxo/provider System/Provider interface.

Note that the interface would also be implemented by a dual DHT Sweeping Provider.

We can extend the interface as needed (e.g Stats()).

---

Kubo integration

If we want both Provide systems (go-libp2p-kad-dht:Provider and boxo:Provider) to be swappable in kubo (at least for a transition period), it would be convenient to have a common interface for both systems.

IMO it is easier to wrap boxo:Provider around go-libp2p-kad-dht:Provider than the other way around, since go-libp2p-kad-dht:Provider is "richer".

However, go-libp2p-kad-dht:Provider doesn't have a concept of Reprovide to trigger a general reprovide of all keys, which is required by boxo:Provider. AFAIK only the ipfs routing reprovide command is using boxo:Provider.Reprovide, so it should be easy enough to cast and if the provide system in use in kubo is boxo:Provider, the reprovide command happens as it used to, otherwise mark it as deprecated with the new provide system.

If boxo:Provider is wrapped in the go-libp2p-kad-dht:Provider interface, StartProviding(), InstantProvide() and ForceProvide() could be mapped to boxo:Provider.Provide(), and StopProviding() would be a noop.

---

@lidel @hsanjuan @gammazero WDYT? We can still change the interface easily at this point.

[guillaumemichel]

This interface is currently named Reprovider, in go-libp2p-kad-dht/reprovider.

I figured the name Provider makes more sense since its users only need to know that this is a content routing provider. They don't need to know the internals of whether the content has to be reprovided. The goal is to signal that the Provider takes the responsibility to advertise content as needed to the remote content routing system (DHT here).

I initially chose Reprovider because go-libp2p-kad-dht/providers/ already exists, and because kubo Provider is the old boxo providing system. I now think it makes more sense to use Provider.

[gammazero]

I think that a Provider interface makes most sense.

[lidel]

nit: name tbd, but should reflect this is ing version that needs to be stopped

Suggested change

	ForceProvide(context.Context, ...mh.Multihash) error
	StartProvidingAndForceInstantProvide(context.Context, ...mh.Multihash) error

[guillaumemichel]

ForceStartProviding?

[hsanjuan]

I wrote this a few day ago. Mostly comments about namings. Along same lines of more recent comments.

[hsanjuan]

Not saying it must, but perhaps can be merged into StartProviding(ctx, now bool, mh.Multihash)

[hsanjuan]

Alternative names ProvideNow or just Provide.

Very explicit: ImmediateSingleProvide().