feat(gnoland): Define and implement SponsorTransaction concept

[linhpn99]

Blocked by #2209

This PR performs the following tasks:

1. Refactor the code structure in the gnoclient directory : remove redundant code, and write reusable functions
2. Update the logic in the anteHandler to allow the creation of a non-existent on-chain account if it is processed in a valid sponsor transaction (I need to review this part)
3. Define a new concept of sponsor transaction in gnoclient: it is a type of transaction signed twice, first by the person who wants to perform the transaction, and second by the person sponsoring the gas for this transaction. A transaction is considered a sponsor transaction when it contains a vm.MsgNoop as the first message in the list of messages
4. Similarly, support the sponsor transaction feature in gnokey (I am not sure if this is necessary)
5. Implement necessary test cases for the newly added/updated code mentioned above
6. A demo with gnokey will be uploaded in the comments section below
7. A full-flow demo with UI describing the process of a user performing a gas-sponsored transaction

From Proposal #2152 :

• Before integrating this pull request (PR) into the main codebase, thorough testing and evaluation are crucial. Once verified, we can explore its integration into an external decentralized application (sponsor service) to cover gas fees for user transactions

• Instead of users directly interacting with the blockchain (like sending tokens or calling specific Realm functions), they will engage with a sponsor service. Users will sign and send requests to the sponsor service , which will handle all necessary checks for their on-chain address. If everything checks out, the sponsor service will countersign the transaction, and cover the gas fees

• Updates to the vm handler module: A NoopMsg has been defined in this PR to skip gas consumption calculation for messages bearing the dApp's signature. These modules will only process messages (e.g., Run, Call, AddPkg, Send) with user-provided arguments, tagging the caller as their on-chain address

• At the conclusion of the process, users can filter events to track the outcomes effectively

• Now we are finalizing the sponsor service implementation for the full-flow design described below

Related Pull Requests:

1. feat(examples): Implement sponsors (p+r) for sponsor service management #2411: This pull request introduces a set (p+r) to manage onchain sponsor services
2. feat(gnoland): Define NoopMsg to facilitate the creation of sponsor transaction (gasless transaction) #2209: This pull request introduces a sponsor management concept

I greatly appreciate everyone's feedback to improve this feature.

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.

[linhpn99]

I created a demo using gnokey to show how this feature works, assuming that the user (who wants to perform an on-chain action without paying gas fees) and sponsor (who covers all the gas fees) are on the same machine and use the same keybase. The steps and outputs are described below :

Case where the user account already exists on-chain

1. Both the user and the sponsor have accounts that exist on-chain
2. The user creates a transaction containing a no_op message (contains sponsor's address)
3. The user signs the created transaction
4. The sponsor signs the transaction that the user has previously signed (in practice, this step requires a way to transmit the transaction from the user to the sponsor)
5. The sponsor broadcasts the transaction to the chain

The result is that the user's balance remains unchanged, and all transaction fees are deducted from the sponsor's balance

Case where the user account does not yet exist on-chain

The steps are similar to the previous case (the difference being that the query results show that the user account does not yet exist on-chain)

The result is that the user account has been created on-chain with a balance of 0, and the public key is set to the public key that the user used to sign the initial transaction

[codecov]

Codecov Report

Attention: Patch coverage is 63.24786% with 86 lines in your changes missing coverage. Please review.

Project coverage is 60.59%. Comparing base (f04ec89) to head (82409ad).
Report is 7 commits behind head on master.

Files with missing lines	Patch %	Lines
gno.land/pkg/integration/testing_integration.go	22.72%	16 Missing and 1 partial ⚠️
gno.land/pkg/keyscli/run.go	0.00%	13 Missing and 1 partial ⚠️
tm2/pkg/crypto/keys/client/send.go	0.00%	14 Missing ⚠️
tm2/pkg/crypto/keys/client/maketx.go	33.33%	12 Missing ⚠️
tm2/pkg/crypto/keys/client/sign.go	80.55%	5 Missing and 2 partials ⚠️
gno.land/pkg/keyscli/maketx.go	0.00%	6 Missing ⚠️
gno.land/pkg/sdk/vm/msgs.go	53.84%	6 Missing ⚠️
gno.land/pkg/keyscli/addpkg.go	85.71%	1 Missing and 1 partial ⚠️
gno.land/pkg/keyscli/call.go	85.71%	1 Missing and 1 partial ⚠️
gno.land/pkg/sdk/vm/handler.go	0.00%	2 Missing ⚠️
... and 2 more

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #2630      +/-   ##
==========================================
+ Coverage   60.44%   60.59%   +0.15%     
==========================================
  Files         563      563              
  Lines       75159    75323     +164     
==========================================
+ Hits        45427    45644     +217     
+ Misses      26343    26284      -59     
- Partials     3389     3395       +6     

Flag	Coverage Δ
contribs/gnodev	61.46% <ø> (ø)
contribs/gnofaucet	14.46% <ø> (-0.86%)	⬇️
misc/genstd	80.54% <ø> (ø)
misc/logos	19.88% <ø> (ø)
tm2	62.16% <58.42%> (+0.10%)	⬆️

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.

[linhpn99]

Drafting to revise code
Ready for the next review

[linhpn99]

Please focus on writing usage examples. It's painful to review an implementation that doesn't demonstrate clear expected usages.

Write better txtar tests.

Besides diversifying the test cases (unit tests, integration tests & txtar), i'm still figuring out how to clearly demonstrate the use case of this feature

[leohhhn]

#2333 (comment)