Feat/reward pool refactor #1976

[shannonwells]

Goal

The goal of this PR is to implement a "chunk" version of the overall reward pool history to reduce read/write load and hence weight for transactions and on_initialize when a new RewardEra needs to start.

Part of #1976

Discussion

This is is just one part of optimizing storage access. There will be more work later.

The current era Reward Pool and a ProviderBoostHistories record are updated on every provider_boost and unstake (for a boost account) call.

Instead of storing all overall Reward Pool history in a single CountedStorageMap, store the current total stake for the current era separately, and divide the actual past era history up into BoundedBTrees. The BTrees are of size RewardPoolChunkLength. These are in a StorageMap indexed by a u32 which is just the chunk index from 0 to history-size/chunk-length - 1.

This is unsurprisingly more complicated than the original solution, however it does have some advantages.

• It reduces reads and writes when there is a new Reward Era and for claiming and listing unclaimed rewards. Because each chunk is a BTree, on a new Reward Era you just remove the oldest and insert the newest into each chunk.
• It reduces reads when listing unclaimed rewards, and will reduce needed reads+writes when claim_rewards is implemented (because it will use the same function).
• It slightly reduces the weight of a stake/unstake because the current total stake is stored separately from Reward Pool History.
• It reduces the storage size of the reward pool history, generally, to just the total staked instead of a struct with 2 other values that aren't needed.

Checklist

• Tests added
• Benchmarks added
• Weights updated
• Migration to initialize ProviderBoostRewardPools storage and CurrentEraProviderBoostTotal
• Verify migration works

[wilwade]

Wanting to go ahead and dump ideas. Got through most of pallets/capacity/src/lib.rs

[wilwade]

🚢 it