Asset Pallet: Support repeated destroys to safely destroy large assets

[tonyalaribe]

Problem:

This is an attempt at solving #12275.
At the moment when an asset with a very large number of accounts (sufficients) eg u32:Max is to be destroyed, the weight would simply be impossible to fit into a block.

Approach:

This PR will make it possible to call the destroy action repeatedly, and at each call account up to a certain max value would be destroyed, until all the accounts have been destroyed.
The current approach involves breaking down the destroy extrinsic into four new extrinsics:

• start_destroy : Mark the asset as being in a destroying state.
• destroy_accounts : Can be called repeatedly until all accounts are destroyed. Only destroys max T:RemoveKeysLimit::get() keys at a time
• destroy_approvals : Can be called repeatedly until all approvals are destroyed. Only destroys max T:RemoveKeysLimit::get() keys at a time
• finish_destroy : Release the currency and finally delete the asset.

cumulus companion: paritytech/cumulus#1742

[gilescope]

this could have it's own ensure_live(details)?; function as it comes up a lot.

[tonyalaribe]

You're right, but this logic is in a lot of places, and I don't want to add more things to this PR. I would rather as a different task

[tonyalaribe]

bot merge

[librelois]

We are currently integrating this change into Moonbeam and do not understand the need for this migration: https://github.com/paritytech/substrate/pull/12310/files#diff-b4f24881ddef27f3416692a99eef0ffdd5af704ec20ff3c3033124f4a818cc63

The new AssetStatus enum is scale encoded the same way as a bool for the first 2 variants, so what is the purpose of this migration? Can we consider not including it in our runtime upgrades?

[tonyalaribe]

Hi @librelois, to the best of my knowlege, i would play safe and run the migration if you already store asset metadata via this pallet. The migration basically sets a default AssetStatus for the existing assets. I'm not very sure you would be able to decode them otherwise.

[librelois]

The migration basically sets a default AssetStatus for the existing assets

Ok, in this case I confirm that this migration is totally useless. The data being encoded in SCALE format, a format which does not include any typing information in the encoded bytes.
SCALE encodes enum variants in one byte by assigning the number zero to the 1st variant, one to the 2nd variant, and so on, so the 1st variant is encoded exactly as false (and the 2nd variant exactly as true).

[ggwpez]

Yea it should be not needed. Did not look too closely initially, but it should encode the same.