Issue Summary

We want to be able to dynamically resize the block cache to avoid running into out-of-memory (OOM) situations. Rather than treating the block cache as a fixed-size allocation, mongotune should be able to shrink or disable it when memory pressure is high, and grow or re-enable it when memory is available again. This ticket is about defining that policy: the rules and signals that govern when the block cache should give back memory versus when it should reclaim it.

Context

• The block cache currently has a static footprint, which can contribute to OOM under memory pressure.
• We need to decide what signals drive the decision (overall memory pressure, cache hit/miss rates, eviction pressure, etc.) and what the safe thresholds are.
• Two directions of change must be covered: freeing memory (resize down or disable the block cache) and reclaiming memory (resize up or re-enable it).

Proposed Solution

• Define when it is the right time to free the block cache's memory — i.e. resize it down or disable it entirely — to avoid OOM.
• Define when it is the right time to re-enable the block cache or let it grow again once pressure subsides.
• Specify the mongotune policy: the inputs/signals it observes, the thresholds, and the actions it takes.
• Deliverable: a documented policy (design) that a follow-up implementation ticket can build against.