Improve config and docs around Experimental.AcceleratedDHTClient and Reprovider

[lidel]

Ref. https://github.com/ipfs/kubo/blob/master/docs/experimental-features.md#accelerated-dht-client

I think it would be useful to give an example of what user can expect when Experimental.AcceleratedDHTClient is enabled.

Initial notes

Maybe just show how expected load looks like?

Below is an example done with AcceleratedDHTClient running on a desktop PC, providing 2M of CIDs every 6 hours (Reprovider.Interval set to 6h)

The above shows that the client is refreshing the map of the DHT periodically (blue "In" spikes), so it always has pretty fresh view of the network.

On a cold boot, after DHT is mapped for the first time, the node will go full throttle and start announcing Provider Records on DHT (the first orange "Out" spike).

Then, it will repeat it every Reprovider.Interval (the second orange spike after 6h).

ipfs stats provide for the above two provide sessions

TotalProvides:          4M (4,136,909)
AvgProvideDuration:     169µs
LastReprovideDuration:  5m49.762073s
LastReprovideBatchSize: 2M (2,068,471)

This should be enough for people to reason how long provide session is expected to take (AvgProvideDuration*number of CIDs)

TODO

• land feat: increase default Reprovider.Interval #9326 first
• create example with Reprovider.Interval set to default value from the config – this is important, so people don't copy&paste 6h, or set it to 6h because that is what official example said :)

[MichaelMure]

Related question: I've seen in https://github.com/ipfs/kubo/blob/master/docs/experimental-features.md#accelerated-dht-client that the accelerated DHT is not able to function as long as the first scan didn't finish. Is that still correct? Any advise to address that? I suppose some doc improvement around that (quite important) topic would help.