…olana-labs#8065)

Processing new epoch (`Bank::process_new_epoch`) involves collecting
stake delegations twice:

1) In `Bank::compute_new_epoch_caches_and_rewards`, to create a stake
   history entry and refresh vote accounts.
2) In `Bank::get_epoch_reward_calculate_param_info`, which is then used
   in `Bank::calculate_stake_vote_rewards` to calculate rewards for
   stakers and voters.

The overall time of crossing the epoch boundary is ~519ms:

```
update_epoch_us=519953i
```

Where the two heaviest operations are `collect()`` calls on stake
delegations, each of them taking ~200-220ms.

Reduce that to just one collect by passing the vector 1) with freshly
computed stake history and vote accounts to `Bank::begin_partitioned_rewards`.
This way, we can avoid calling `Bank::get_epoch_reward_calculate_param_info`.

The new time of crossing the epoch boundary is ~337ms:

```
update_epoch_us=337371i
```

Making that change possible required several refactors:

* Tale `&PointValue` in `Bank::create_epoch_rewards_sysvar`. That makes
  it easier to operate on references of `PartitionedRewardsCalculation`.
  Copying integers from `PointValue` is cheap and has no visible
  performance impact.
* Split `Stakes::activate_epoch`, that was performing calculations and
  mutating the cache at the same time. The calculations got split to
  `Stakes::calculate_activated_stake` that takes `&self`.
* Add `Stakes::stake_delegations_ves` method. Stake delegations are
  stored as hash array mapped trie (HAMT)[0], which means that inserts,
  deletions and lookups are average-case O(1) and worst-case O(log n).
  However, the performance of iterations is poor due to depth-first
  traversal and jumps. Currently it's also impossible to iterate over it
  with rayon. That issue is known and handled by converting the HAMT to
  a vector with `stakes.stake_delegations.iter().collect()`. Move that
  trick to a dedicated method that describes the performance
  consequences.
* Add `FilteredStakeDelegation` wrapper type, that wraps a vector of
  stake delegations and acts as a lazy iterator that filters out ones
  with insufficient stake.
* Split the code dealing with rewards calculation and vote rewards
  distribution into separate methods:
  * `Bank::calculate_rewards` that takes `&self` and does not acquire
    any locks.
  * `Bank::begin_partitioned_rewards` that takes `&mut self`, sets
    calculation status and creates a sysvar.
  * `Bank::distribute_vote_rewards` that stores partitioned rewards and
    increases capitalization.

[0] https://en.wikipedia.org/wiki/Hash_array_mapped_trie

Fixes: solana-labs#8282

…olana-labs#8065)

Processing new epoch (`Bank::process_new_epoch`) involves collecting
stake delegations twice:

1) In `Bank::compute_new_epoch_caches_and_rewards`, to create a stake
   history entry and refresh vote accounts.
2) In `Bank::get_epoch_reward_calculate_param_info`, which is then used
   in `Bank::calculate_stake_vote_rewards` to calculate rewards for
   stakers and voters.

The overall time of crossing the epoch boundary is ~519ms:

```
update_epoch_us=519953i
```

Where the two heaviest operations are `collect()`` calls on stake
delegations, each of them taking ~200-220ms.

Reduce that to just one collect by passing the vector 1) with freshly
computed stake history and vote accounts to `Bank::begin_partitioned_rewards`.
This way, we can avoid calling `Bank::get_epoch_reward_calculate_param_info`.

The new time of crossing the epoch boundary is ~337ms:

```
update_epoch_us=337371i
```

Making that change possible required several refactors:

* Tale `&PointValue` in `Bank::create_epoch_rewards_sysvar`. That makes
  it easier to operate on references of `PartitionedRewardsCalculation`.
  Copying integers from `PointValue` is cheap and has no visible
  performance impact.
* Split `Stakes::activate_epoch`, that was performing calculations and
  mutating the cache at the same time. The calculations got split to
  `Stakes::calculate_activated_stake` that takes `&self`.
* Add `Stakes::stake_delegations_ves` method. Stake delegations are
  stored as hash array mapped trie (HAMT)[0], which means that inserts,
  deletions and lookups are average-case O(1) and worst-case O(log n).
  However, the performance of iterations is poor due to depth-first
  traversal and jumps. Currently it's also impossible to iterate over it
  with rayon. That issue is known and handled by converting the HAMT to
  a vector with `stakes.stake_delegations.iter().collect()`. Move that
  trick to a dedicated method that describes the performance
  consequences.
* Add `FilteredStakeDelegation` wrapper type, that wraps a vector of
  stake delegations and acts as a lazy iterator that filters out ones
  with insufficient stake.
* Split the code dealing with rewards calculation and vote rewards
  distribution into separate methods:
  * `Bank::calculate_rewards` that takes `&self` and does not acquire
    any locks.
  * `Bank::begin_partitioned_rewards` that takes `&mut self`, sets
    calculation status and creates a sysvar.
  * `Bank::distribute_vote_rewards` that stores partitioned rewards and
    increases capitalization.

[0] https://en.wikipedia.org/wiki/Hash_array_mapped_trie

Fixes: solana-labs#8282