Prototypes, make check working

updates to impl design doc

refinements to design doc

Implement the basic functionality of tracking and rotating Reward Era. Closes #1567
Does not include anything to do with the Reward Pool.

- [x] Chain spec updated
- [x] Design doc(s) updated
- [x] Tests added

The goal of this PR is to implement a really basic version of the
StakingRewardsProvider in the Capacity pallet and in the test mock,
neither of which is actively used.

Closes #1572

Does not include anything to do with setting and storing RewardPoolInfo
when each new Era starts.

- [x] Design doc(s) updated
- [x] Tests added

* Make some functions pass by reference (performance)
* fix broken tests & calls

…/adjust tests

* Performance: move non-db checks to top when retargeting
* Lots more tests
* Fix a bug where we weren't setting the staking type on a retarget
* Remove staking type from StakingAccountDetails
* Fix broken tests from last commit

The goal of this PR is to implement storage of reward pool history.

Closes #1710

The goal of this PR is to split the `stake` extrinsic into two: `stake` and `provider_boost`
Closes #1707

The goal of this PR is to split up storage of boosting and maximized staking accounts,
as well as store retarget history separately, which can store retargeting events for
any type of staking.

Closes #1726

* Lots of rattle, causing several helper functions to be split up -
rather than having a bunch of conditionals due to type differences.
* In the interest of limiting the size of this PR/merge into the branch
I left a lot of TODOs for when reward pool updates on a
stake/boost/unstake is resumed

* set the amount of capacity generated by a provider boost to the final amount, 50% of what is generated by MaximizedCapacity staking.
* Also Fixes some tests broken from the last rebase with main.
Closes #1569

The goal of this PR is to update the StakingRewardPool on a `provider_boost` or `unstake` extrinsic call.

Closes #1699

Also includes a bunch of lint changes

- [x] Design doc(s) updated
- [x] Tests added
- [x] Benchmarks corrected and updated
- [x] Weights updated

The goal of this PR is to implement (but not really use yet) the chosen
formula for calculation of a reward in a single Provider Boost Reward
Era.

Closes #1941

The goal of this PR is to add and use storage for individual staking history so that rewards can be calculated and paid out.  Benchmarks run to update capacity weights.

Relates to #1699

The goal of this PR is to update the benchmark for `on_initialize` to include the weight when a new RewardEra must be created.

Closes #1949

The goal of this PR is to implement `list_unclaimed_rewards`, and also
one that is lighter weight, `has_unclaimed_rewards`, which returns a
`bool` and which `unstake` extrinsic uses. Unstake now fails if there
are any unclaimed rewards.

Closes #1969
Closes #1578

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

Co-authored-by: Wil Wade <wil.wade@amplica.io>

# Goal
The goal of this PR is to review and update the implementation design doc in light of the chosen economic model, and to reflect some changes in behavior.  Review of the design doc also fed back into the code itself. Some code
is no longer needed.

Closes #2016 
---------

Co-authored-by: Aramik <aramikm@gmail.com>

The goal of this PR is to add some e2e tests for the `provider_boost` extrinsic, and update the `change_staking_target` extrinsic after a rebase with main.

# Goal
The goal of this PR is primarily to pull RewardEra out of the Capacity Config and make it the same type everywhere.

Other changes in this PR that were incidental to this refactor
* I renamed staking_events in testing_utils, because it captures all the events from the pallet.
* I pulled out RewardEraLength into constants so it could be different for different environments.

Related to #1970

The goal of this PR is to implement the claim_staking_rewards extrinsic, its benchmarks, and tests.

Closes #1970

# Goal
The goal of this PR is to implement a capacity runtime api for the `list_unclaimed_rewards` endpoint.

Following the current recommendation of Parity, there is no custom RPC matching this runtime API endpoint; instead, use state.call to access the endpoint. For examples using either Observable or APIPromise, see the e2e tests.

Closes #1698

Add a minor test case to unstaking tests
Add new extrinsics to Capacity README

…-rewards-impl

# Conflicts:
#	runtime/frequency/src/lib.rs

…-rewards-impl

# Conflicts:
#	runtime/frequency/src/lib.rs

…-rewards-impl

# Conflicts:
#	e2e/package-lock.json
#	pallets/capacity/src/weights.rs
#	runtime/frequency/src/lib.rs

# Goal
The goal of this PR is to fix a flaky e2e test for
`capacityRuntimeApi.listUnclaimedRewards`

# Discussion

- Remove redundant definitions in api-augment for Capacity
- Updated the test to not be dependent on starting just before an era

Co-authored-by: Puneet Saraswat <61435908+saraswatpuneet@users.noreply.github.com>

# Goal
The goal of this PR is to removed added getters

Related to #2105

…-rewards-impl

# Conflicts:
#	designdocs/provider_boosting_implementation.md
#	pallets/capacity/src/lib.rs
#	pallets/capacity/src/tests/stake_and_deposit_tests.rs
#	pallets/capacity/src/tests/unstaking_tests.rs
#	pallets/capacity/src/tests/withdraw_unstaked_tests.rs

Passkey check only balance not nonce and don't pre-fund it

Working consistently

# Goal
The goal of this PR is to address some feedbacks

- added feature flags for test only methods
- added a constant
- small refactor

# Goal
Reward eras were 1-indexed but this made things too confusing.

* Use unwrap_or_default for getting a reward pool chunk
* warning for inserting a new chunk failure
* code golf
* linting in e2e
* remove unnecessary change in helpers

…ists for a different provider (#2136)

## Summary

A user can stake to multiple providers, but the minimum staking amount
is enforced only for the first staking action that the user submits.

## Issue details

During the staking process, both for the `stake` and `provider_boost`
extrinsics, a minimum staking amount should be enforced by the
`Runtime::MinimumStakingAmount` parameter.

The current implementation of
[ensure_can_stake](https://github.com/frequency-chain/frequency/blob/9ef58185f2230aaf92dc166fb8eade56a78e4cf3/pallets/capacity/src/lib.rs#L638)
verifies if the amount that the account is staking in total (the current
active staking and the new staking amount) is greater than the
`MinimumStakingAmount`:

```rust
let new_active_staking_amount = staking_details
	.active
	.checked_add(&stakable_amount)
	.ok_or(ArithmeticError::Overflow)?;

ensure!(
	new_active_staking_amount >= T::MinimumStakingAmount::get(),
	Error::<T>::StakingAmountBelowMinimum
);
```

This implies that the user has to stake the `MinimumStakingAmount` only
when they first submit a stake for a provider, all the subsequent
staking requests being accepted even with the amount of 1.

## Risk

The current implementation does not follow the intended use-case, as
described in the design documentation.
An attacker could stake the minimum required amount to a provider, and
then stake 1 token to each of the other available providers, underpaying
for the storage that they use. This can cause a storage bloating,
slowing down the network in the long run.

## Mitigation

The `ensure_can_stake` function should verify that the `stakable_amount`
is greater than `MinimumStakingAmount`, instead of verifying the
`new_active_staking_amount`.

Closes #2135 

# Discussion

- `ensure_can_stake` updated to remove the addition of the existing
stakes and check `stakable_amount`
- `get_stakable_amount_for` updated to use `reducible_balance` as
recommended by parity when using the `fungible` trait.
`reducible_balance` requires an Existential Deposit, so the unit test
values were updated.
- `/designdocs/capacity.md` updated to the latest code, and reflects
changes in language due to replacing `lock`s with `freeze`s.
- CI Checks are not running on this branch, but the unit tests and e2e
tests passed in local.

# Checklist
- [ ] Updated Pallet Readme?
- [ ] Updated js/api-augment for Custom RPC OR Runtime API?
- [x] Design doc(s) updated?
- [ ] Unit Tests added?
- [ ] e2e Tests added?
- [ ] Benchmarks added?
- [x] Spec version incremented?

---------

Co-authored-by: Wil Wade <wil.wade@amplica.io>
Co-authored-by: Shannon Wells <shannonwells@users.noreply.github.com>