Dust account handler

[girazoki]

This PR adds a Dust account Handler that receives the dust from the initialization phase. This happens in the case after the initialization has completed the fund pot is slightly bigger than the initialized rewards

[girazoki]

One thing we can do is leave this dust in this pallets account. It should be barely significant so we might well just have the new check but do nothing with the dust

[JoshOrndorff]

Can you say more about when / why dust might remain? And why that is acceptable? Are we talking about rounding errors or something? Is there an upper bound on hoe much dust might exist?

A more Substrate-y way to handle this might be to use an imbalance. https://crates.parity.io/frame_support/traits/tokens/imbalance/index.html

[girazoki]

Sure.

The way I am calculating rewards is fund_pot/total_ksm_contribution, and then multiplying by the contribution of each account. However this yields a float number, so I need to round it down. The maximum dust this process can generate is 1 unit per contributor, or in other words, total_num_of_contributors units. I am OK handling with the imbalance, with another account, or even not handling it but the current situation is this:

• When I create the rewards, there is a missmatch between the fund pot and the sum of the rewards. Without this PR, the requirement is that the sum of the rewards and the fund pot should match exactly. To bypass this I am creating a dummy contributor to absorb the imbalance, but this obviously is a hack.

So essentially, there is a number of things we could do:

• Make another account (e.g. treasury) absorb this imbalance.
• Burn this imbalance
• Dont do anything, but relax the total_rewards == fund_pot requirement to total_rewards >fund_pot - total_contributors

[girazoki]

After talking to @crystalin we decided we will burn it. I will update the PR to reflect this

[girazoki]

Updated, first time I handle burns and imbalances so please make sure I havent made a mistake