TransactionFrame Refactor

[SirTyson]

Description

Resolves #2163

This PR makes all TransactionFrame variants immutable. All mutable state, such as TransactionResult and caches has been moved to the TransactionResultPayload class. Hash caches are still in TransactionFrame, but only because the contents they hash are immutable such that the cache can never be invalidated.

To maintain our current testing framework, TransactionTestFrame acts as a wrapper class, combining an immutable TransactionFrame with it's associated TransactionResultPayload object for easier testing.

Checklist

• Reviewed the contributing document
• Rebased on top of master (no merge commits)
• Ran clang-format v8.0.0 (via make format or the Visual Studio extension)
• Compiles
• Ran all tests
• If change impacts performance, include supporting evidence per the performance document

[dmkozh]

Thanks for dealing with this mess! I didn't have time to review everything, just mostly looked at the new interfaces.

[dmkozh]

I actually think this won't be too much of a problem for parallelization: cached accounts only really matter for replay, so we won't have real-time network transactions racing with apply, because we're only dealing with past transactions here (of course later we'd need to add something defensive to the code to ensure that)

We also can keep the cache only used prior to protocol 8, right?

[marta-lokhova]

We also can keep the cache only used prior to protocol 8, right?

I think that's what we do already? we're keeping it around to correctly apply the buggy behavior during replay, but we don't need this cache for normal in-sync operations.

[SirTyson]

I've finished up another round of refactoring that hopefully should better divide the responsibilities of the TxFrames. Changes include:

• Account cache is stored in TransactionFrame again
• OperationsFrame is now immutable
• TransactionFrame stores OperationFrames again
• MutableTransactionResult (formerly TransactionResultPayload) has been simplified to only support basic get/set operations of result state
• Soroban related state has been refactored into it's own class/interface
• TransactionFrame and OperationFrame are responsible for all functions that modify the result state and write to the blockchain, but must take a MutableTransactionResult

There are three distinct responsibilities:

1. Basic stateless wrapper around TransactionFrame XDR (TransactionFrame)
2. Mutable result state of a transaction (MutableTransactionResult)
3. Applying Transactions to the Blockchain (functions live in TransactionFrame, but requires MutableTransactionResult object).

I think TransactionFrame is still doing too much, and ideally I'd like to break the responsibility from 3. into a new class (something like TransactionFrameApplicator). For a first pass though, I think making OperationFrames immutable and be owned by TransactionFrame gives us a much clearer distinction of responsibility than the first refactor.

[dmkozh]

LGTM, thanks.

[marta-lokhova]

just a few questions. I haven't finished reviewing everything yet, but it's moving in the right direction!

Also, any thoughts on the test/rollout plan for this change? Given the blast radius of a bug in any of the Transaction/OperationFrame codepaths, I think in addition to full replay, we could utilize the fuzzer (I'm not certain what shape it's in though)