feat: add /r/sys/vals

[zivkovicmilos]

Description

This PR introduces an initial validator set implementation in Gno (realm based), as outlined in #1824.

I've added 2 example implementations:

• PoS (Proof of Stake) - users can stake funds (ugnot) to become part of the on-chain validator set
• PoA (Proof of Authority) - new validators need to be voted in by the majority of the existing validator set

I've left the door open to arbitrary protocol implementations (Proof of Contribution...).

Closes #1824

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

All modified and coverable lines are covered by tests ✅

Project coverage is 54.67%. Comparing base (edb321f) to head (997f6af).

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #2130      +/-   ##
==========================================
+ Coverage   54.64%   54.67%   +0.03%     
==========================================
  Files         578      577       -1     
  Lines       77870    77671     -199     
==========================================
- Hits        42551    42468      -83     
+ Misses      32149    32049     -100     
+ Partials     3170     3154      -16     

Flag	Coverage Δ
gnovm	59.99% <ø> (ø)

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.

[moul]

please, please, please, do NOT use this. especially on sys contracts.

[zivkovicmilos]

Do you suggest we simply return the typed set itself, instead of marshaling it to JSON?
The biggest concern I have there is that clients will be unable to parse the returned set, because our VM calls return values that need custom parsing (and don't contain type info)

[moul]

About std.Emit in your contract:

1. You can keep it for external users.
2. However, you cannot use it to transfer data from the userland to the module. Instead, you should use a returned value that is explicitly typed and returned, making it easily testable and type-safe. Use a gno.Machine and call an unexported function getChanges from your realm to retrieve the changes and reset the changes set. For now, you can use simple types, but later we may need to improve to use ABCI types from the userland or what Guilhem is working on with Amino.
3. You can keep the event trigger routing in this PR, but it would also be acceptable/(preferred?) to keep this PR super simple and only perform gno.Machine verification at each block until another PR improves the gnosdk with this optimized triggering logic.

[zivkovicmilos]

@moul

However, you cannot use it to transfer data from the userland to the module. Instead, you should use a returned value that is explicitly typed and returned, making it easily testable and type-safe. Use a gno.Machine and call an unexported function getChanges from your realm to retrieve the changes and reset the changes set. For now, you can use simple types, but later we may need to improve to use ABCI types from the userland or what Guilhem is working on with Amino.

I've applied the following suggestions in this commit:

• keep events minimal (they don't transfer data)
• expand the /r/sys/vals realm to keep track of changes
• added an unexported getChanges function that will return set changes between calls
• change the API of the underlying Protocol implementations to return the validator if it's been added / removed (or nil if the action was a noop), instead of relying on events to transmit this data. We need this because we need to preserve the data about a validator's voting power etc prior to their removal / addition (you can see how we use this info in the /r/sys/vals wrapper methods

997f6af

You can keep the event trigger routing in this PR, but it would also be acceptable/(preferred?) to keep this PR super simple and only perform gno.Machine verification at each block until another PR improves the gnosdk with this optimized triggering logic.

We left this logic for #2229 -- after the minimal event footprint in this PR, we can make the logic work as follows:

• catch events protocol level that something happened (these events are typed)
• run the VM to execute getChanges()
• use the fetched result to construct an Endblocker response