Restructure transaction traces

[arhag]

Change Description

Resolves #6897.

Modifies transaction trace structure:

• Adds new optional field account_ram_delta to transaction_trace which, if present, tracks the delta in RAM usage for the payer for the deferred transaction. (Note that the RAM initially billed for a contract-generated deferred transaction is not included as part of this field.)
• Removes inline_traces from action_trace and switches to flat structure for all action traces.
• Adds the following fields to action_trace:
  • receiver which is the receiver of the action (identical to the one inside the receipt, if present);
  • action_ordinal an unsigned integer used to identify the action trace within the transaction;
  • creator_action_ordinal is the ordinal of the action trace that is the parent of the current action trace within the creation tree representation of the transaction trace;
  • parent_action_ordinal is the ordinal of the action trace that is the parent of the current action trace within the execution tree representation of the transaction trace.

On error, the transaction trace will now included the action traces for any actions that were scheduled but not yet successfully executed by the point of the error. Any action that has not successfully executed will have an empty receipt.

The history_plugin, mongo_db_plugin, and state_history_plugin have been modified to work with the transaction_trace structure.

The push_transaction and push_transactions RPCs of the chain API have been modified to convert the new transaction trace structure back into a format similar to the old structure prior to returning the converted result back to the client. The converted structure recovers the old "execution tree" representation (using the inline_traces field which is brought back) that existing clients may be expecting. However, the new fields in both transaction_trace and action_trace are still included in this converted structure.

A new RPC send_transaction has been added to the chain API which does the same thing as push_transaction except it does not do any conversion back to the old structure. It returns the transaction_trace as it is with the new flat structure.

New test cases have been added to api_tests to verify the structure of the transaction_trace after executing variations of the example scenario discussed in #6897.

Consensus Changes

• Consensus Changes

API Changes

• API Changes

Add send_transaction RPC to chain API.

Documentation Additions

• Documentation Additions

Documentation will need to be updated to include the new send_transaction RPC as part of the chain API. send_transaction is preferred over push_transaction since it avoids doing the additional conversion work that push_transaction now does to support backwards compatibility.

The structure of transaction_trace has been modified which has an impact to any plugins that may be consuming the applied_transaction signal.