rpc: Fix deserialization of /block_results response when some tx results are non-ok

[romac]

See informalsystems/hermes#3817 (comment) for background.

---

• Referenced an issue explaining the need for the change
• Updated all relevant documentation in docs
• Updated all code comments where relevant
• Wrote tests
• Added entry in .changelog/

[codecov-commenter]

Codecov Report

Attention: 3 lines in your changes are missing coverage. Please review.

Comparison is base (194d81e) 59.0% compared to head (7388d27) 58.7%.
Report is 4 commits behind head on main.

❗ Current head 7388d27 differs from pull request most recent head 205ba79. Consider uploading reports for the commit 205ba79 to get more accurate results

Files	Patch %	Lines
rpc/tests/sei_fixtures.rs	97.4%	1 Missing ⚠️
tendermint/src/chain/id.rs	0.0%	1 Missing ⚠️
tendermint/src/error.rs	0.0%	1 Missing ⚠️

Additional details and impacted files

@@           Coverage Diff           @@
##            main   #1391     +/-   ##
=======================================
- Coverage   59.0%   58.7%   -0.4%     
=======================================
  Files        275     274      -1     
  Lines      27930   27975     +45     
=======================================
- Hits       16505   16443     -62     
- Misses     11425   11532    +107     

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

[romac]

@mzabaluev We should probably do something smarter in cometbft-rs, eg. model ExecTxResult as an enum rather than have all successful and failing fields in the same struct.

[mzabaluev]

@romac

We should probably do something smarter in cometbft-rs, eg. model ExecTxResult as an enum rather than have all successful and failing fields in the same struct.

Good idea. Which fields should be represented in results with Code != 0? I see "log" and "codespace" fields in these fixtures. What about "info"?

[romac]

Good question, I don't know! The fixture does not feature it in either case. Might have to check out the CometBFT source code to figure when it's included.

[mzabaluev]

Note that you can already match on the abci::Code domain type. As for whether the other fields may be present in ExecTxResult of a failed transaction, I can find no normative information on this. As far as I can see in the CometBFT source, result are only formed by test code, there are no helper methods to guide applications on how to properly report failures.

codespace perhaps only makes sense for non-zero codes and could be a member of redesigned Code::Err. log and info could be set with useful information in failure cases as well.
gas_wanted, gas_used, and events only make sense in the success case.