spike: Snapshot-based TreasuryGovernor

[victorges]

What does this pull request do? Explain your changes. (required) This is to demonstrate the implementation described in this document regarding a stake snapshot-based voting power system for an on-chain treasury fueled by inflationary rewards.

Specific updates (required)

• BondingManager changes to mint a % of inflation to a treasury() contract
• BondingManager changes to notify treasury governor about staking updates
• TreasuryGovernor implementation to handle all of the above. Including:
  • Using transcoder recorded totalStake in BondingManager for historical transcoder stake
  • A checkpointing ("snapshotting") logic of delegator's bonded amount and delegated address
• Also implemented the voting "override" logic for a delegator changing their transcoder vote. _countVote function
• Refactor updates: https://github.com/livepeer/protocol/pull/611#issuecomment-1574483763

There are some obvious missing pieces there like integrating this with our Controller abstractions (and whether we should use our proxy or OZ's).

How did you test each of these updates (required) This is all currently untested, which is what I'll be working on now.

Accept tips on how to test from an existing state like mainnet right now snapshotted to a test env 🤔

Does this pull request close any open issues? Δ

Checklist:

• [ ] README and other documentation updated
• [ ] All tests using yarn test pass

[victorges]

FTR I've moved the code around a bit to resemble what their final organization might look like. 3 new contracts now:

• BondingCheckpoints contains only the checkpointing logic tied to the bonding manager
• GovernorVotesBondingCheckpoints contains governor voting logic based on the above checkpoints
• TreasuryGovernor is the actual governor impl, which is almost empty now

Also added some other comments to the code as I went through it with more info or TODO reminders (feel free to make comments on them in the PR as well)

[yondonfu]

I don't recall if this was explicitly covered elsewhere, but it is also important to define whether the snapshot of voting power is taken at the start or end of a round.

IIUC:

If the snapshot of voting power is taken at the start of a round N (i.e. the first block of the round) then we should fetch the delegator's stake as of the end of round N - 1. This implies fetching the most recent delegator checkpoint before round N and setting the end round for the cumulative earnings calculation to round N - 1.

If the snapshot of voting power is taken at the end of a round N then we should fetch the delegator's stake as of the end of round N. This implies fetching the most recent delegator checkpoint before or equal to round N and setting the end round for the cumulative earnings calculation to round N.

[victorges]

We are done with this phase!