Background node fetching for storage writes

[Longarithm]

With flat storage released, we don't necessarily have to read nodes to get an old value during storage_write execution. We can reuse prefetcher functionality to schedule background node reads, so that contract won't be blocked on IO latency, and in the end of chunk processing, when it's time to create new nodes out of old ones, most of old nodes are already fetched.

At first, we implement simple prototype to check feasibility. Perhaps we need to have a separate PrefetchApi for now.

Idea originates from here.

Dedicated GDrive with docs and progress: https://drive.google.com/drive/folders/1hysZYMZfsfGdfk1WUJgUj7R2MpLASGfC

2023 July milestones

• Implementation done by 30% (TODO - define what it means)
• Align on cost model

[Longarithm]

July results:

• Implementation - wasn't started;
• Align on cost model - our hypothesis on existence of suitable gas model failed.

We spent 4 weeks in July on it. Most of the time was spent on carefully aggregating receipts data and understanding the impact of gas model change (doc). We had one conversation about how we can communicate receipt failures/cost increases.

However, later I realized that we don't have enough evidence for this gas model proposal. We could propose higher costs, but it would dramatically increase number of failing receipts. After thet, we tried to understand how we could proceed with background fetching without significant cost changes and formulated a new proposal (another doc).

Ideas for August:

• Align on implementation without gas cost changes
• Prove with benchmarking that it solves cause of July mainnet incident

[Longarithm]

Won't needed because of near/near-one-project-tracking#5