add status field to response in RPC methods tx, EXPERIMENTAL_tx_status, broadcast_tx_commit, broadcast_tx_async

[telezhnaya]

This PR is a part of RPC tx methods redesign https://docs.google.com/document/d/1jGuXzBlMAGQENsUpy5x5Xd7huCLOd8k6tyMOEE41Rro/edit?usp=sharing
Addressing point 3 in #9542 and start working on #6837

Changes:

• New field status appeared in the response of RPC methods tx, EXPERIMENTAL_tx_status, broadcast_tx_commit, broadcast_tx_async
• Added some comments with the explanations

In #6837, Illia suggested to have the structure

enum BroadcastWait {
 /// Returns right away.
 None,
 /// Waits only for inclusion into the block.
 Inclusion,
 /// Waits until block with inclusion is finalized.
 InclusionFinal,
 /// Waits until all non-refund receipts are executed.
 Executed,
 /// Waits until all non-refund receipts are executed and the last of the blocks is final.
 ExecutedFinal,
 /// Waits until everything has executed and is final.
 Final,
 }

I've renamed it to TxExecutionStatus and simplified it a little by dropping all refund options:

1. We may add them later without breaking backwards compatibility
2. To support them, we need to have the access to receipt (it's the method get_tx_execution_status). We have there only execution_outcome by default. We created special logic to be able not to retrieve the receipts (it's the only difference between tx and EXPERIMENTAL_tx_status). I have a feeling (please correct me here if I'm wrong) that retrieving corresponding receipt may slow down the execution that we tried to optimise.
   BTW, maybe the data from execution_outcome is enough (we have there gas_burnt and tokens_burnt). @jakmeier suggested the condition outcome.tokens_burnt == 0 && outcome.status == Success. Unfortunately, we need to work with any status. But maybe the first part (outcome.tokens_burnt == 0) is enough to say that it could be only refund receipt. I need more input here.

[telezhnaya]

@wacban @jakmeier adding you back :)
I can't mark this PR as "ready for the review", it's still too raw.
Though I need your attention here. Could you please have a look at the general approach? Any of your input will be appreciated.

In the meantime, I'll think about tests. For now, I just roughly fixed the existing ones

[nikurt]

Thinking about the corner cases from a point of view of a user:

• Submit a transaction
• Transaction gets included in a block in a fork
• See that the transaction is included in a block
• Wait for 10s
• See that the transaction is included in a block
• Wait for 10s
• .. repeat forever

Should we help the user in this case?
IIUC, this infinite loop is not possible with the execution of receipts, because the outgoing receipts of the parent block must be included in the child block.
Inclusion of transactions is different, because it is not mandatory.

A counter-argument would be that a transaction may never be included in any block by chunk producers, and we can't possibly verify this condition.

[telezhnaya]

After we merge this, I'll start working on adding the same struct to the request to all the methods touched in this PR. It should solve this issue at least partially.

Thank you for the review!
I've addressed all the other comments and added the notes to CHANGELOG.md, please have a look again

[nikurt]

👍 👍 👍