Emit event when changing total locked value in pallet-balances

[sea212]

Fixes #12276

This PR adds two events to the balances pallet, namely:

/// Some free balance was locked out from specific operations.
Locked { who: T::AccountId, amount: T::Balance, reason: Reasons },
/// Some balance that was locked out from specific operations was freed.
Unlocked { who: T::AccountId, amount: T::Balance, reason: Reasons },

Since locks in the same category of Reasons overlay each other, the design decision was made to include only the changes of total lock value in the amount fields of the respective events. Examples:

Locks = [10/MISC]          --> [15/MISC]              // emits Locked(..., amount=5, Reasons::Misc)
Locks = [15/MISC]          --> [15/MISC, 20/MISC]     // emits Locked(..., amount=5, Reasons::Misc)
Locks = [15/MISC, 20/MISC] --> [17/MISC, 20/MISC]     // emits nothing
Locks = [17/MISC, 20/MISC] --> [20/MISC]              // emits nothing
Locks = [20/MISC]          --> [10/MISC]              // emits Unlocked(..., amount=10, Reasons::Misc)
Locks = [10/MISC]          --> [10/MISC, 15/FEE]      // emits Locked(..., amount=15, Reasons::Fee)
Locks = [10/MISC, 15/FEE]  --> [20/MISC, 20/FEE]      // emits Locked(..., amount=10, Reasons::Misc) and
                                                      // emits Locked(..., amount=5, Reasons::Fee)
// etc.

There are also alternative approaches that could be applied:

1. Add total_locked field to the respective events.
2. Emit lock event that only contains total_locked instead of the amount that was added to or removed from the total lock value.

Some questions in regards to the actual changes in this PR:

1. Currently Reasons::All is not used in the event. There is a corner case when a lock is set with Reasons::All that implies the same relative change of lock amounts for both Reasons::Misc and Reasons::Fee (all currently available reasons). In that case the event could emit Reasons::All. I decided against adding this because in terms of implementation effort this does not scale well at all. Instead, two distinct events are now emitted.
2. The PR contains this logic: if a > b then a - b and if a < b then b - a. Is it okay to use non-saturating math here or is using saturating math only enforced meanwhile?

[cla-bot-2021]

User @sea212, please sign the CLA here.

[melekes]

👍 (code-wise; don't know enough to reason about business logic)

[ggwpez]

Putting it up for audit 👍

[ggwpez]

bot rebase

[paritytech-processbot]

Rebased

[ggwpez]

Is it okay to use non-saturating math here or is using saturating math only enforced meanwhile?

Would be okay here. But since you already have it - its doing no harm.

[ggwpez]

Emit lock event that only contains total_locked instead of the amount that was added to or removed from the total lock value.

I think both is fine. In both cases you either dont have the diff or not the total but putting both in the event could be done 🤷‍♂️

[bkchr]

bot rebase

[paritytech-processbot]

Error: Command 'Command { std: "git" "push" "--porcelain" "sea212" "balances-add-lock-events", kill_on_drop: false }' failed with status Some(1); output: error: failed to push some refs to 'https://x-access-token:${SECRET}@github.com/sea212/substrate.git'

[bkchr]

@sea212 please merge master.

[sea212]

Does anyone know what is going on here in regards to the CI? If I run the command locally all tests pass. The changes in this PR are even not related to the errors that occur.

@bkchr @kianenigma @ggwpez @melekes

[paritytech-processbot]

Error: Statuses failed for d01e57b

[bkchr]

bot rebase

[paritytech-processbot]

Rebased

[bkchr]

bot merge

[paritytech-processbot]

Waiting for commit status.

[paritytech-processbot]

Merge cancelled due to error. Error: Statuses failed for 2e8c08d

[paritytech-cicd-pr]

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable
Logs: https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/2589497

[ggwpez]

Master is red now, but there were internal CI problems. Will fix.