provider: add a buffered KeyChanFunc.

[hsanjuan]

This provider helper allows to buffer all the results from a keyChanFunc in memory.

The purpose is to fix issues with slow re-providing. In the case of ipfs/kubo#10596, the slow re-providing process causes starvation of any operations trying to read/write to the pinset.

With the new buffered KeyChanFunc, we can read everything we need to announce into memory first, and free any locks as soon as possible.

Given the compact size of CIDs (<50bytes), I don't think any complexer approach (batch reading and lock/unlock handling) is justified. People with pinsets of 20 million items that want to announce everything can well spare an extra GB of RAM. For smaller repos the impact becomes negligible.

The test targets precisely the use-case and ensures we don't starve operations while interacting with dspinner.

[guillaumemichel]

The reasoning and the code make sense. The windows CI doesn't seem happy with the tests though

[hsanjuan]

yeah @gammazero is this related to dequed "power of two" grow allocations?

[gammazero]

is this related to dequed "power of two" grow allocations?

I do not think so. It does not look like your test creates such a huge number of pins that it should cause OOM. Besides, the grow by power of two is what a slice does anyway. I will test this locally and see what it eating up all the memory.

The deque is very memory efficient when inflow and outflow are somewhat balanced, i.e. when size changes do not incur many queue resizes. However, if the use pattern is to enqueue a large (relative to the base capacity) amount of data and then read all of the data, then a better deque implementation is this: https://github.com/edwingeng/deque. It really depends on the use pattern which is more efficient.

[hsanjuan]

The test failure was due to recursion when ipld-prime traverses a 4092-deep graph.

[gammazero]

See comment.