Delete the block_cache

[michaelsproul]

Proposed Changes

The block_cache was disabled by default for hindering performance. We have no plans to re-enable it, and likely a performant replacement would look somewhat different from what we have now.

This PR deletes the block_cache implementation entirely, achieving a slight simplification of our DB code, and also takes aim at the do_atomically_with_block_and_blobs_cache method which IMO was overly complicated for little gain.

Additional Info

TODO:

• Deprecate CLI flag (with warning).
• Consider re-adding cache for DataColumnCustodyInfo.
• Rename do_atomically_with_block_and_blobs_cache to something more appropriate.
• Work out whether we need a garbage collection/"hard pruning" for dangling blobs/columns.

[michaelsproul]

@eserilev Did you remember if caching the DataColumnCustodyInfo had a noticeable performance benefit? I think it probably helps a bit, but we also don't load it very often.

[eserilev]

@michaelsproul we don't load it very often. The only places it's used is when responding to Status and DataColumnByRange RPC requests and during custody backfill. During custody backfill and DataColumnByRange RPC requests any performance benefits from caching this value seems negligible to me, since we're already reading and/or writing from/to disk.

I don't know how often we respond to Status requests. But without caching we'd now have to read from disk when responding to this request. Doesn't seem like a big deal to me, but we could cache it in a similar way that we cache AnchorInfo, BlobInfo, etc.

[michaelsproul]

I'll try measuring it. I suspect LevelDB would cache it in memory for us anyway if we are reading frequently for status messages. Also wouldn't be too hard to cache as you said