chore: introduce back-pressure to tiered storage

[romange]

Also some changes to mac-os build (still disabled).

[dranikpg]

Do we break atomicity assumptions by yielding here?

Yes, if the value is visible by iterating over the cursor, offloading might try to offload it. That's the tiering part. Not sure how holding a prime value pointer interferes with other actions like eviction, etc.

---

I still don't understand the idea of throttling. All of the code exists purely to offer faster writes than a disk would allow, yet we cap ingestion performance by disk speed? Why don't we provide backpressue only when we've filled up our memory budget? If our depth is too large, we can just discard the write - offloading will take care of it in the future

[romange]

Couple of points here:

1. We do not cap by disk bandwidth, we slow down and maybe abort the offloading,
   therefore the writes will still be much faster.
   DEBUG POPULATE 10000000 .. was slowed down by just 2 seconds with this heuristic, on my machine.
2. You idea of providing backpressure when we are closer to memory limit is better but it also more complicated.

Given that this implementation is buggy, I will convert it to a NOOP in case we are have too many pending io requests, as you suggested.
In any case, we must respect tiered_storage_write_depth because otherwise will will use too much memory on writes in transit. Also, overloaded queues will affect read latencies.