Make some DI responses synchronous

[Kailai-Wang]

Context

Partially implemented #1883, it's divided into multiple PRs as otherwise the PR would be too big

solves #1883

This PR:

• laid down skeleton to make response synchronous
• apply parentchain effects for failed STFs too
• store the RPC responses to top pool
• embed top_hash into TrustedOperationStatus
• devise a way to deliver synchronous responses for streamed trustedCalls (e.g. link_identity)
• refactor some of the trusted calls - they should return Err so that the synchronous DI response shows Invalid
• responses to these calls are synchronous now:
  • set_user_shielding_key
  • activate_identity
  • deactivate_identity
  • set_identity_networks
  • link_identity

The parachain callbacks are preserved to make CI backwards compatible. If you send one of the DI requests above, you should see both the rpc response AND the parachain event.

Now the WorkerRpcReturnValue would have the following structure, example of set_user_shielding_key:

setUserShieldingKey call returned {
  value: '0x8eaf04151687736326c9fea17e25fc5287613693c912909cb226aa4794f26a48fcc5ab7556950296f4f3042fd955b1a281f7683ad07cf54819ab4d4921c636f8c61a250d01bc98d1b3dd8a4e49bfaa1f17fe9d0a086e950a40c58a6a20f3152f00d0964c0fc62a4b7640706f048bda3725e56e2882631916e924d9d8133e2d628a8317593fe5a245dcf7f969e0',
  do_watch: false,
  status: {
    TrustedOperationStatus: [
      [Object],
      '0x0c2612dc5372b7ba83cbc33b1f2023cb287a7c6546ed79b53921b04dc109ca7e'
    ]
  }
}

value would contain the encoded *Response struct, please refer to the test code in DI-sample.

TODO (see comment in trusted_call.rs)

• Display error details in synchronous DI responses #1928
• Implement synchronous DI response for request_vc #1929

[codecov-commenter]

Codecov Report

Merging #1920 (073abef) into dev (5a493f9) will decrease coverage by 0.16%.
The diff coverage is 0.00%.

❗ Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.

@@            Coverage Diff             @@
##              dev    #1920      +/-   ##
==========================================
- Coverage   17.67%   17.51%   -0.16%     
==========================================
  Files         272      272              
  Lines       12936    13054     +118     
==========================================
  Hits         2287     2287              
- Misses      10649    10767     +118     

Impacted Files	Coverage Δ
tee-worker/app-libs/stf/src/stf_sgx.rs	0.00% <0.00%> (ø)
tee-worker/app-libs/stf/src/trusted_call.rs	0.00% <0.00%> (ø)
...orker/core-primitives/stf-executor/src/executor.rs	0.00% <0.00%> (ø)
tee-worker/core-primitives/stf-executor/src/lib.rs	0.00% <0.00%> (ø)
...e-worker/core-primitives/stf-executor/src/mocks.rs	0.00% <0.00%> (ø)
...-worker/core-primitives/stf-interface/src/mocks.rs	0.00% <ø> (ø)
...rker/core-primitives/top-pool-author/src/author.rs	0.00% <0.00%> (ø)
...orker/core-primitives/top-pool-author/src/mocks.rs	0.00% <ø> (ø)
...-worker/core-primitives/top-pool/src/basic_pool.rs	0.00% <0.00%> (ø)
...ee-worker/core-primitives/top-pool/src/listener.rs	0.00% <0.00%> (ø)
... and 17 more

[Kailai-Wang]

Hold on - maybe I can finish the streamed trustedCall part

[kziemianek]

I noticed several warnings in tee-worker logs while running test-identity:local ts-tests aganist this implementation

[2023-07-24T21:07:06Z INFO  itc_direct_rpc_server::rpc_responder] set response value
[2023-07-24T21:07:06Z WARN  itp_top_pool::watcher] failed to set response value to rpc client: InvalidConnectionHash

It looks like it doesn't make sense to invoke set_rpc_response_value for TOPs that originates from indirect calls.

[Kailai-Wang]

I noticed several warnings in tee-worker logs while running test-identity:local ts-tests aganist this implementation

[2023-07-24T21:07:06Z INFO  itc_direct_rpc_server::rpc_responder] set response value
[2023-07-24T21:07:06Z WARN  itp_top_pool::watcher] failed to set response value to rpc client: InvalidConnectionHash

It looks like it doesn't make sense to invoke set_rpc_response_value for TOPs that originates from indirect calls.

I believe you'll see such warnings even for DI requests due to potential early hash swap. The swap is called in another thread, and there's no guarantee that the previous top is already imported in the sidechain block at that time. In fact, for most of the time it's not yet included in the block.

Therefore later when the previous top does get included in the block, the top pool watcher tries to send out the response and finds out the channel doesn't exist any more, hence the warning. It's expected behavior and should be fine in such case.

[kziemianek]

By making these changes and using rpc return values only for indirect calls I managed to get rid of all [WARN itp_top_pool::watcher] failed to set response value to rpc client: InvalidConnectionHash log entries.

[kziemianek]

Looks good 👍🏼