feat(gnoland): Define NoopMsg to facilitate the creation of sponsor transaction (gasless transaction)

[linhpn99]

Update 2024-06-19 : This PR is in the process of refactoring the sponsor transaction section. It will be open for review when completed
Update 2024-06-26 : Ready to review
Update 2024-07-25 : The sponsor transaction section has been moved to #2630

From Proposal #2152:

This PR Introduces a new message type vm.MsgNoop: a type of message that does not trigger any logic processing in the vmHandler

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 and implement SponsorTransaction concept #2630: This pull request enhances the gnoclient by introducing the ability to create and send a sponsor transaction through the definition of a noopMsg

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: Patch coverage is 68.75000% with 15 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
tm2/pkg/sdk/testutils/testutils.go	46.15%	7 Missing ⚠️
gno.land/pkg/sdk/vm/msgs.go	53.84%	6 Missing ⚠️
tm2/pkg/std/tx.go	83.33%	1 Missing and 1 partial ⚠️

📢 Thoughts on this report? Let us know!

[linhpn99]

From issue #2182
@moul should i implement MsgNoop like this PR ?
If you have free time, please take a look and give me feedback if there is anything unreasonable so we can move forward

[thehowl]

Can you explain why you need this?

[linhpn99]

Can you explain why you need this?

I want a feature where a user who owns the native token (sponsor) can cover the gas fees for a user who does not own the native token (sponsoree), allowing them to perform on-chain actions with their messages (such as calling a realm function)

detail here : #2152 & #2630

[moul]

The goal of NoopMsg is to be a message that does nothing and is as small as possible once transmitted and stored.
Then, we can use it in multi-message transactions to experiment with gas sponsorship.

[github-actions]

This PR is stale because it has been open 3 months with no activity. Remove stale label or comment or this will be closed in 3 months.

[Gno2D2]

I'm a bot that assists the Gno Core team in maintaining this repository. My role is to ensure that contributors understand and follow our guidelines, helping to streamline the development process.

The following requirements must be fulfilled before a pull request can be merged.
Some requirement checks are automated and can be verified by the CI, while others need manual verification by a staff member.

These requirements are defined in this configuration file.

Automated Checks

🟢 Maintainers must be able to edit this pull request
🔴 The pull request head branch must be up-to-date with its base

Manual Checks

• The pull request description provides enough details

Debug

Automated Checks

Maintainers must be able to edit this pull request

If

🟢 Condition met
└── 🟢 On every pull request

Then

🟢 Requirement satisfied
└── 🟢 Maintainer can modify this pull request

The pull request head branch must be up-to-date with its base

If

🟢 Condition met
└── 🟢 On every pull request

Then

🔴 Requirement not satisfied
└── 🔴 Head branch (linhpn99:define-MsgNoop) is up to date with base (master): behind by 201 / ahead by 24

Manual Checks

The pull request description provides enough details

If

🟢 Condition met
└── 🟢 Not (🔴 Pull request author is a member of the team: core-contributors)

Can be checked by

• team core-contributors