[Manta] Asset-Manager and XCM

[stechu]

Description

closes: #297

Manta Asset-Manager and XCM code.

Manta/Calamari Asset Design:

1. Each asset has a unique identifier within Manta/Calamari, which is a u32 typed AssetId, this include both XCM assets, Manta/Calamari’s native token, and customized assets in Manta/Calamari (in the future)
2. Pallet-Asset-Manager is the centralized interface for asset management, it supports:
   1. Create a new asset
   2. Update the metadata of current asset
   3. Freeze/Unfreeze an asset (Native asset cannot be frozen)
   4. Change AssetLocation of an existing asset
   5. Change UnitPerSecond of an existing asset

Manta/Calamari XCM Fee Payment Mechanism:

1. When transferring Manta/Calamari native asset, we charged a fixed rate fee on KMA/MANTA. This is defined on the first element of Trader of XcmConfig (FixedRateOfFungible)
2. When transferring other asset, we always charge the first kind of assets (when calling buy_weight(weight, payment) , the first asset in payment). We maintain a UnitPerSecond rate for each asset we support in pallet-asset-manager. During a single XCM execution, we expect that the user should use the same kind of assets to buy weight. If a user use the different kind of asset to buy weights during a single XCM execution, we only handling the refund of the first kind of asset being used to buy weights. (see FirstAssetTrader code)

---

Before we can merge this PR, please make sure that all the following items have been
checked off. If any of the checklist items are not applicable, please leave them but
write a little note why.

• Targeted PR against correct branch (manta or dolphin) with right title (start with [Manta] or [Dolphin]),
• Linked to Github issue with discussion and accepted design OR have an explanation in the PR that describes this work.
• Wrote unit tests.
• Updated relevant documentation in the code.
• Re-reviewed Files changed in the Github PR explorer.
• If runtime changes, need to update the version numbers properly:
  • authoring_version: The version of the authorship interface. An authoring node will not attempt to author blocks unless this is equal to its native runtime.
  • spec_version: The version of the runtime specification. A full node will not attempt to use its native runtime in substitute for the on-chain Wasm runtime unless all of spec_name, spec_version, and authoring_version are the same between Wasm and native.
  • impl_version: The version of the implementation of the specification. Nodes are free to ignore this; it serves only as an indication that the code is different; as long as the other two versions are the same then while the actual code may be different, it is nonetheless required to do the same thing. Non-consensus-breaking optimizations are about the only changes that could be made which would result in only the impl_version changing.
  • transaction_version: The version of the extrinsics interface. This number must be updated in the following circumstances: extrinsic parameters (number, order, or types) have been changed; extrinsics or pallets have been removed; or the pallet order in the construct_runtime! macro or extrinsic order in a pallet has been changed. If this number is updated, then the spec_version must also be updated
• If needed, notify the committer this is a draft-release and a tag is needed after merging the PR.
• Verify benchmarks & weights have been updated for any modified runtime logics
• If needed, bump version for every crate.
• If import a new pallet, choose a proper module index for it, and allow it in BaseFilter. Ensure every extrinsic works from front-end. If there's corresponding tool, ensure both work for each other.
• If needed, update our Javascript/Typescript APIs. These APIs are offcially used by exchanges or community developers.
• If we're going to issue a new release, freeze the code one week early(it depends, but usually it's one week), ensure we have enough time for related testing.

[Dengjianping]

and_then will return Option<Option< MultiLocation>>, ok_or returns a type like Err(()) or Ok(None) or Ok(Some(_)).

AssetInfoGetter::get_asset_location(id.borrow().clone()).and_then(Into::into).flatten().ok_or(())

or

AssetInfoGetter::get_asset_location(id.borrow().clone()).map(Into::into).flatten().ok_or(())

[bhgomes]

Fine from me. Still not clear on the distinction between min_balance and is_sufficient and there are still some open comments by Jamie.

[stechu]

Fine from me. Still not clear on the distinction between min_balance and is_sufficient and there are still some open comments by Jamie.

The semantics is pretty subtle here, I added it to the new comments:

/// * `is_sufficient`: whether this asset can be used as reserve asset,
/// 	to the first approximation. More specifically, Whether a non-zero balance of this asset is deposit of sufficient
/// 	value to account for the state bloat associated with its balance storage. If set to
/// 	`true`, then non-zero balances may be stored without a `consumer` reference (and thus
/// 	an ED in the Balances pallet or whatever else is used to control user-account state
/// 	growth).

[Dengjianping]

Please resolve some clippy warnings.

[Dengjianping]

And do fmt.

[Dengjianping]

LGTM!