feat: Add an error code on the metering middleware

[jubianchi]

This is a proposition for #1931.

⚠️ Do not merge as-is. Wait for #1941 to get merged or to provide an alternative

Basically, the metering middleware now injects a new global, error_code with its own helper get_error_code which will allow the host to correctly handle metering errors. Now, a remaining_points == 0 and error_code != NoError means the execution of the guest module consumed all the gas points.

Review

• Add a short description of the the change to the CHANGELOG.md file

[jubianchi]

ping @webmaster128

[webmaster128]

Looks good, some first thoughts

[MarkMcCaskey]

The structure and design looks reasonable to me! I have some feedback about some of the implementation details though!

[webmaster128]

This PR covers all functionality required for #1931 – very cool. Freel free to reject my suggestions and personal preferences if you don't like them.

One more thing that I can think of (but don't need on my own), is the ability to reset the error. Imagine a use case where Wasm runs for a while and hits a safety limit. Now the user has the choice to resume the execution. Then it would be nice if you could increase the limit and reset the error.

[jubianchi]

@webmaster128 @syrusakbary what do you think of reseting the error each time we call set_remaining_points?

[webmaster128]

@webmaster128 @syrusakbary what do you think of reseting the error each time we call set_remaining_points?

I think there is two layers of abstraction here:

1. getters/setters for the metering state variables
2. a higher level concept of metering points that can be empty or exceeded

In 1., the values are independent and it it would be very confusing if they affect each other when setting them. However, we can think about exposing 2. to user, where

• set_remaining_points resets the error
• get_remaining_points returns an

  enum MeteringPoints {
      /// The given amount of points >= 0 is left 
      Remaining(u64),
      /// The limit was exceeded
      Depleted,
  }

This would remove the impossible state error = 1 and points > 0 from the user's handling code.

[jubianchi]

@webmaster128 thanks for the suggestion.

I like the second proposition. @syrusakbary @nlewycky what do you think about that?

[webmaster128]

Cool API

[jubianchi]

bors try

[bors]

try

Build succeeded:

• Audit
• Code lint
• Test on linux-x64
• Test on windows-x64
• Test on linux-aarch64
• Test on macos-x64
• Test cross-compile on linux
• Test cross-compile on macos

[webmaster128]

Great work. Some ideas, feel free to dismiss. The only thing we should clean up one way or another is the exports.

[MarkMcCaskey]

bors r+

[bors]

Build succeeded:

• Test cross-compile on macos
• Test on linux-x64
• Test on linux-aarch64
• Test on windows-x64
• Audit
• Code lint
• Test on macos-x64
• Test cross-compile on linux