Support block replayability with enabled flat storage

[Longarithm]

With flat storage enabled, we currently don't support state-viewer apply range command. See original discussions here and here.

So far we know that:

• it is annoying to some developers, as this command is useful for them for replaying blocks and get proxies for performance estimation;
• replaying blocks is an actual usecase by some NEAR users, though there was no critical demand for it so far.

So this is considered lower priority than #7327. However, let's provide several options to solve it.

Recreate FS

Just create FS from scratch, using trie. @mm-near confirmed once that it takes < 1h on rpc nodes.

Concerns

• If shard size is too big, FS creation time grows with it.
• Waiting for 1h to replay a single block is annoying.

Recreate "partial" FS

Some kind of hack: store all trie keys ever read for each specific block; if we need to replay a block, create "partial" FS including only these keys and execute a block, no issue should occur.

Concerns

• We don't store these "trie keys ever read" now. If we have some range in history for which they are not stored, it is not clear how to create this "snapshot".
• Increase of disk usage

Fallback to Trie

Fallback to Trie makes a lot of sense; however, it would spoil chunk cache. But it can be solved if we specifically disable chunk cache during storage_read, and other storage ops when we use FS there as well.

Concerns

• Design of chunk cache will be even more hacky. It is already annoying to enable/disable chunk cache before/after funcall execution.

FS rollback

If block to replay is not far away, we can rollback flat storage, until its head is the same as desired block.

Concerns

• We don't support rollback yet. Storing "old" values in deltas is technically annoying but can be done in, say, 2-3 weeks.
• If block is too far away (years ago?), rollback takes a lot of time.

[Longarithm]

WIth in-memory trie implemented, we have an option to implement which shouldn't consume crazy amount of time.
Say, in 1 hour we create in-memory trie for shard from archival node data, then create flat storage for shard, then replay chunk. It will be helpful to replay incidents.

[robin-near]

On the "Recreate partial FS" idea, can we run these transactions once, mark all the storage that is needed to run them, populate partial FS, and then execute them again for real?

[Longarithm]

Configuration removed in #10490 can be helpful to replay chunks without having flat storage at all.