[move] vouch reputation

[0xzoz]

NOTE: This is a sketch for all practical purposes. No tests have been written for new features (it's a sketch, incomplete, and by definition broken until tested). The previous tests are all passing.

Background
Over the last week(21/04/24) it was observed that the validator set had been increasing quite rapidly since the V7 Hard Fork (more info regarding the hard fork: here). Discussion then started in the #validator-operations channel with some feedback. This PR is intended to hold a template and act as a place for discussion regarding a solution to the hard problem of Sybil Prevention within the validator set of the 0L Network.

Implementation
This makes the execution of features dependent on separate admin actions, but the code deployed in advance for state to begin populating.

I.e if all features are implemented it would require multiple steps for data to get populated, so I implemented with feature flags.

Phase 1: Leaderboard and simple Reputation score begin getting populated

• Cap number of outbound/given vouches at 10
• Create threshold for min number of required vouches based on validator set size (x/10 + 1)
• Cost to vouch is also dynamic: it's the same as one nominal epoch reward (currently it's basically zero at 0.001 Libra)

Phase 2: Feature Flag dynamic_vouch_limit

• Enables dynamic max limit vouches given updates based on simple Reputation score. (no reputation equals zero outgoing vouches).

Phase 3: Feature Flag recursive reputation
if enabled, calculates a recursive reputation for 1 hop away from the vouchers and vouchees

@0o-de-lally doesn't necessarily endorse this... It was created to add all the requested features into one codebase for demonstration.

[0xzoz]

I think all of these are good additions that increase the visibility into potential attacks and decrease the risk of sybils. One item Ive been thinking about is what to do if you do get into a situation that requires remediation before a network halt and subsequently messy rescue mission.

Sui implements a reporting feature that is used as a social mechanism instead of protocol layer slashing. https://docs.sui.io/guides/operator/validator-tasks#reportingun-reporting-validators

Essentially each validator has a score card with binary bits for each of the other validators in a set. If a validator suspects that I am a sybil or bad operator they would then report me setting the corresponding value from 0 -> 1. If 2f +1 validators do this for my validator then I lose my staking rewards in the sui implementation.

This could be repurposed to remove sybil validators from the set and would require a majority to do so. This acts inverse to a sybil attack(1f + 1) by using the same value as consensus(2f + 1)

[0xzoz]

Added as #246 for easy collaboration between contributors