Move accounts data size checks to end of ReplayStage

[brooksprumo]

Problem

Accounts data size checks must be deterministic. Their current location is not, since batches are replayed in parallel, thus transaction processing order is non deterministic.

For more context, see #26439

Summary of Changes

All the checks for accounts data size violations have been moved to the end of replay stage, once the bank is complete. At this point, we check the accounts data size to see if there were violations either within the block or for the total size.

This must happen deterministically. Are there any negative performance impacts these checks may have? I've tried to make the checks as small and infrequent as possible; can they be further reduced?

Fixes #26439
Feature Gate Issue: modifies #24135 and #25517

Builds on

• Remove bank test_max_accounts_data_size_exceeded() #26772
• Remove accounts data size checks in blockstore_processor #26776
• Do not check accounts data size in InvokeContext #26773

[stale]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[brooksprumo]

Hi folks, thanks in advance for taking a look to review this PR. For some additional context, here's why I've asked each of you:

@brennanwatt: You touched this code most recently but allowing concurrent replay. Would love your expertise on perf and soundness.
@AshwinSekar: I ran these ideas by you, so wanted to make sure this looked right by you.
@jstarry: You found the issue to begin with.
@Lichtso: You wanted to make sure we still have test coverage for the accounts data size checks that were removed in other locations.

Also, please let me know if some parts need more explanation. Each person likely has a different level of familiarity with both this code and this issue, so happy to help in anyway.

Pull request has been modified.

[bw-solana]

LGTM

[jstarry]

I prefer banking stage changes to be made first so that we don't get into a situation where leaders unknowingly produce blocks with invalid allocations. Banking stage has some checks in cost tracker that prevent more than 100MB of allocations from system program allocations but it could be circumvented by reallocating in other programs such that the replay stage check gets triggered and marks the slot as dead.

[jstarry]

Aside: I don't think this MAX_ACCOUNT_DATA_BLOCK_LEN constant is very clearly named. It represents how much additional account data can be allocated in the block but the name implies that this is how much account data that can be accessed in the block. Maybe MAX_BLOCK_ACCOUNT_DATA_SIZE_DELTA?

[brooksprumo]

Closing this PR as it cannot be merged. It would introduce potential non-determinism. For more information, please refer to #27029