provider: simplify reprovide

[guillaumemichel]

Follow up to #871 and part of https://github.com/ipshipyard/roadmaps/issues/6 / https://github.com/ipshipyard/roadmaps/issues/7

Hopefully it will help with ipfs/kubo#10714

Previous behavior was hanging on a select waiting for context to be cancelled.

If the warning message 🔔🔔🔔 YOU ARE FALLING BEHIND DHT REPROVIDES! 🔔🔔🔔 keeps coming, while the reprovideInterval is set to 0, it means that Reprovide was called (probably from kubo, with ipfs routing reprovide?).

EDIT: the reprovide warning issue seems to come from kubo

[gammazero]

The stopAndEmptyTimer is not needed since go.123 is required. Call the timer's Stop method instead. Handled in change 0301460

[gammazero]

As noted by @aschmahmann : If your node reboots do you re-advertise all your data again even if it's within the reprovide interval?

If this is an intended behavior change then it should be documetned in release notes.

[guillaumemichel]

If your node reboots do you re-advertise all your data again even if it's within the reprovide interval?

Right, I missed why the reprovide times were persisted to the datastore. I reverted and documented this behavior.

I also corrected a corner case. Previously, a node rebooting, that would have have to reprovide in 1h if it hadn't rebooted, would not reprovide on reboot, but would wait reprovideInterval(=22h) before reproviding, implying that the reproviding would be 21h late.

In the fix, the first provide is either reprovideInterval after the last reprovide written in the datastore, or after initialReprovideDelay if the last reprovide was more than reprovideInterval ago or if no last reprovide date was found.

Added a changelog entry, since this last change actually modifies the behavior.

[gammazero]

LGTM