feat(gnoclient): add MultiCall

[leohhhn]

Description

This PR introduces a the MultiCall feature to the Gnoclient. It allows for packing multiple vm.MsgCall messages into a single transaction, then signing & publishing it.

The PR utilizes the same API, just allows for multiple MsgCall messages in the CallCfg struct, and parses accordingly.

cc @zivkovicmilos @moul @jefft0

Contributors' checklist...

• Added new tests, or not needed, or not feasible
• Provided an example (e.g. screenshot) to aid review or the PR is self-explanatory
• Updated the official documentation or not needed
• No breaking changes were made, or a BREAKING CHANGE: xxx message was included in the description
• Added references to related issues and PRs
• Provided any useful hints for running manual tests
• Added new benchmarks to generated graphs, if any. More info here.

[codecov]

Codecov Report

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

Comparison is base (cfd5d33) 56.13% compared to head (60b5963) 47.25%.
Report is 1 commits behind head on master.

Files	Patch %	Lines
gno.land/pkg/gnoclient/util.go	43.75%	6 Missing and 3 partials ⚠️
gno.land/pkg/gnoclient/client_txs.go	73.33%	6 Missing and 2 partials ⚠️
gno.land/pkg/gnoclient/client.go	0.00%	2 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #1565      +/-   ##
==========================================
- Coverage   56.13%   47.25%   -8.88%     
==========================================
  Files         438      377      -61     
  Lines       66151    61322    -4829     
==========================================
- Hits        37134    28980    -8154     
- Misses      26126    29953    +3827     
+ Partials     2891     2389     -502     

Flag	Coverage Δ
go-1.21.x	∅ <ø> (∅)
misc	∅ <ø> (∅)
misc-_test.genstd	∅ <ø> (∅)

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.

[zivkovicmilos]

Please see the comments I've left 🙏

I don't think we need another Call method just to support multiple message types, as the functionality is identical, but that we should see how to utilize existing client functionality. The API of any client should be very specific and lean, not wide to accommodate different use-cases. Keep the implementation deep, but the API shallow.

Also, please add unit tests for this functionality 🙏

[leohhhn]

@zivkovicmilos added some tests: fb2416d

[leohhhn]

Putting this on hold until we figure out what the execution semantics and implications are when calling multiple MsgCall Messages in a single transaction. Primary concerns:

• If a single MsgCall reverts, will the whole transaction revert?
• What is the execution order of the MsgCalls? If two MsgCalls are working with the same memory, which will be executed first? Can the second one pick up the change done by the first one?
• etc.

[zivkovicmilos]

Progress, but still not fully there. We are missing critical unit tests for the functionality.

Please see my comments 🙏

[zivkovicmilos]

Putting this on hold until we figure out what the execution semantics and implications are when calling multiple MsgCall Messages in a single transaction. Primary concerns:

• If a single MsgCall reverts, will the whole transaction revert?
• What is the execution order of the MsgCalls? If two MsgCalls are working with the same memory, which will be executed first? Can the second one pick up the change done by the first one?
• etc.

1. Yes, the entire transaction should revert
2. As far as I'm aware, the execution order of messages within a transaction is as they are specified. A former message is working off of the state from the last message during the execution cycle.

[zivkovicmilos]

Thank you for resolving the comments 🙏

I've left final thoughts, which are easy fixes.
Otherwise we should be good to go 🚀

I appreciate you taking the time to resolve everything and learn in the process. Great work 👏