Refactor the balances module

[gavofyork]

Closes #4613

Note that this "cheats" slightly and coalesces WithdrawReasons within balances to just two categories: TransactionPayment (Fees) and everything else (Misc). That allows an aggregate to be stored and avoids lock-list traversals in all balance operations without bloating the account storage item too much. It does mean that locking an account for Transfers now also locks it for Reserves as well, but it's questionable whether they should ever really have been separate in the first place. I left WithdrawReasons as it is since I couldn't see any reason to dumb down the public API just because one implementation happens to implement it in a conservative way.

TODO:

• Make sure I shouldn't be doing anything special with balances being instanceable.
• Test migration.

[gavofyork]

@shawntabrizi any further comments?

[shawntabrizi]

It all looks good to me, although I wonder if the migration logic is too much for a single block...

How will we test?

[gavofyork]

not sure we really can; re: execution-time it's not a big deal - it'll just be a long block. memory usage should be fine in principle, however if there's some issue with memory leakage (like that you found), then it could be a problem. i'd like to know what's going on with that before upgrading.

[gavofyork]

ok - obvious way to test is to dump balances state, spin up a local testnet with it as genesis and then execute with wasm.

[gavofyork]

Tested it on a dev chain, and can confirm it works fine in wasm. (Actually it's surprisingly fast migrating ~7k accounts)

[Polkadot-Forum]

This pull request has been mentioned on Polkadot Forum. There might be relevant details there:

https://forum.polkadot.network/t/moving-frame-out-of-substrate/907/1