refactor: remove majority of as_caching_storage calls

[Longarithm]

TrieStorage::as_caching_storage is a bad design because it requires all implementations of TrieStorage to know about TrieCachingStorage. We needed it to expose storage metrics and caches, see .

Here we remove majority of such calls, except two:

• call inside set_trie_cache_mode - can be fixed during resolving of Explicitly expose trie metrics to TrieStorage callers #9004;
• calls inside prefetcher. @jakmeier do you remember how much prefetcher logic needs to know what TrieStorage it is using?

Testing

Existing tests. We can't test shard cache in test_repeated_values_count anymore, but this makes sense, as caches are hidden implementation detail of TrieCachingStorage.

[jakmeier]

Nice, seems like a good trade-off to remove those assertions but make our code cleaner!

Regarding the prefetcher: I don' remember the details anymore. But looking at the code, I beleive we only use it to access pub fn prefetch_api(&self) -> &Option<PrefetchApi>. Maybe that should become part of the TrieStorage trait?

And once we use it in a test to clear caches. This is a bit annoying because for the prefetcher it is a correctness issue whether something is in the cache or not. Maybe the test can be rewritten somehow.
Or we could also put a clear_cache on the TrieStorage trait. But that seems only slightly better than having as_caching_storage on the trait.

[Longarithm]

Nice, seems like a good trade-off to remove those assertions but make our code cleaner!

These assertions are even not needed because now we can create recording storage over any trie storage.

Maybe that should become part of the TrieStorage trait?

Maybe, I'll try.

And once we use it in a test to clear caches. This is a bit annoying because for the prefetcher it is a correctness issue whether something is in the cache or not. Maybe the test can be rewritten somehow.

Now I think the right way is to add method ShardTries::clear_cache. It has update_cache method anyway.