RPC: improve supporting tx execution levels

[telezhnaya]

More about tx execution levels: https://docs.near.org/api/rpc/transactions#tx-status-result

The levels that allow having not all the execution outcomes (Included, IncludedFinal), actually had to wait for all of the execution outcomes anyway.
[1.37.3 had a separate partial fix for supporting Included status, but let's not overcomplicate]
With the current change, we can show everything we have at the moment without extra waiting.
Also, current change helps us to be 1 step closer to resolving #6834
That would be my next step after we merge this PR.

TLDR: I partially copy pasted the code.
I could have rewritten chain:get_final_transaction_result instead, but it has LOTS of usages everywhere. I decided it's just not safe.
I anyway changed it a little with the new function chain:get_execution_status (hopefully in a better way) - see the details below in the comment.
But the new logic with partial execution outcomes list is used only in view_client (aka RPC, as far as I see from the usages).

[telezhnaya]

I've decided to extract this logic from get_final_transaction_result to a separate function, and rewrite it, fixing a number of potential bugs in the meantime.

Some important context:
The receipt may produce tons of new receipts. However, the corresponding execution outcome will have the status ExecutionStatusView::SuccessReceiptId with only one id inside - it's the last receipt id of all the produced receipts. So if you want to see the status, you have to go through all the list, it's not enough to look at the status of the id inside SuccessReceiptId field.

---

Results

• I started checking all the produced receipts statuses, not only the last one
• I stopped relying on the order of the receipts
• I fixed another bug. Before, we have

match &outcome_with_id.outcome.status {
                         ExecutionStatusView::Unknown if num_outcomes == 1 => {
                             Some(FinalExecutionStatus::NotStarted)
                         }
                         ...
}

In reality, if we have 1 outcome, it means the status is at least Started.

[codecov]

Codecov Report

Attention: Patch coverage is 81.42857% with 13 lines in your changes are missing coverage. Please review.

Project coverage is 71.54%. Comparing base (cbf977a) to head (33174b4).

Files	Patch %	Lines
chain/chain/src/chain.rs	82.25%	8 Missing and 3 partials ⚠️
chain/client/src/view_client.rs	71.42%	2 Missing ⚠️

Additional details and impacted files

@@           Coverage Diff           @@
##           master   #10792   +/-   ##
=======================================
  Coverage   71.54%   71.54%           
=======================================
  Files         758      758           
  Lines      152058   152086   +28     
  Branches   152058   152086   +28     
=======================================
+ Hits       108785   108812   +27     
- Misses      38767    38772    +5     
+ Partials     4506     4502    -4     

Flag	Coverage Δ
backward-compatibility	0.24% <0.00%> (-0.01%)	⬇️
db-migration	0.24% <0.00%> (-0.01%)	⬇️
genesis-check	1.42% <0.00%> (-0.01%)	⬇️
integration-tests	37.17% <44.28%> (-0.01%)	⬇️
linux	70.00% <81.42%> (+<0.01%)	⬆️
linux-nightly	71.03% <81.42%> (+<0.01%)	⬆️
macos	54.53% <70.00%> (+0.01%)	⬆️
pytests	1.65% <0.00%> (-0.01%)	⬇️
sanity-checks	1.44% <0.00%> (-0.01%)	⬇️
unittests	67.17% <70.00%> (-0.01%)	⬇️
upgradability	0.29% <0.00%> (-0.01%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[Longarithm]

Thank you! Please also look at the comments.

Ideally we should have a test for new behaviour. We likely have tests which check that getting recursive outcomes fails at some early block and succeeds later. We can add checks there that getting partial outcomes always succeeds and gives ids which indeed correspond to spawned receipts.