dApp Staking - Improved Tier Threshold Derivation

[Dinonard]

Overview

Currently, tier thresholds are hardcoded and don't depend on the total issuance of the native token.
This isn't the best since total issuance will increase over time - or rapidly decrease as it has recently.
Given the logic behind dynamic thresholds, it's only fair to adjust thresholds to the changing total issuance.

E.g. if total issuance was to be cut in half, thresholds should also be cut in half since tokens are used to stake,
and if there are half tokens compared to before, lots of dApps would loose on tier positions.

Solution Suggestion

This will require a simple storage migration.
New thresholds should only be applied for the future tier assignment, not retroactively for the old assignments.

1. pub enum TierThreshold should be updated to use total issuance percentages instead of hardcoded values

• sanity checks per runtime should ensure these values are within the expected range

2. TiersConfiguration should be updated to no longer use TierThreshold enum but should store numeric threshold directly as a number

• also, number_of_slots can be removed from the struct as it is redundant

Choosing Init Percentages

Compare hardcoded thresholds to the total issuance at the time when dApp staking v3 is launched and calculate the percentage (or perbill) to achieve as close number to that as possible.
This requirement can be slightly relaxed if we can end up with a easier to read perbill number.
E.g. if total issuance was 8.4B ASTR and lower threshold for tier 1 was set to 200M ASTR, dividing those numbers gives
0.023809523809524% which can also be represented as 0.0238 for the sake of readability.