Add low level traits to retrieve name, symbol, decimals and allowance in pallet-assets

[girazoki]

This PR adds an ERC20 compatible trait for fungibles by extending the Inspect trait with name, symbol, decimals, allowance, transfer_from and approve functions.

It also implements such a trait for pallet-assets. This PR does not make any changes to the functionality of pallet-assets but rather moves the approve_transfer and transfer_approved functionality to the functions module. It also uses the existing storage to get the information necessary to satisfy the ERC20 trait

[vgeddes]

I also desire to have more static APIs for pallet-assets, that other pallets can call into. Have been thinking about it a lot too this week. That said I think having such a high-level Ethereum-specific interface in FRAME may not be appropriate.

Rather, we could add new low-level Inspect, and Mutate traits for working with asset metadata and approvals. Users can then build higher-level constructs on top of them.

Rough example: (not too much thought put into it):

// fungibles::metadata::Inspect
trait Inspect<AssetId> {
   fn name(asset: AssetId) -> Vec<u8>;
   fn symbol(asset: AssetId) -> Vec<u8>;
   fn decimals(asset: AssetId) -> u8;
}

// fungibles::metadata::Mutate
trait Mutate<AssetId> {
   fn set(asset: AssetId, name: Vec<u8>, symbol: Vec<u8>, decimals: u8) -> DispatchResult;
}

[girazoki]

Yeah I dont mind dividing this into more low level traits.

[girazoki]

I applied the suggested change. We could also name the traits differently like InspectMetadata and InspectApproval so that we can import them directly.

[shawntabrizi]

Why would name, symbol, or metadata need to be read by another pallet?

This data should only be used off-chain which is why it is not exposed via any traits.

[girazoki]

In the case of Moonbeam we are trying to build an ERC-20-like precompile for assets, which has getters for those attributes. In any case we are more interested in the allowance getter, which is the one we trully need, we could live without the metadata getter

[vgeddes]

For Snowbridge, we are interested more in allowing another pallet to set/mutate metadata for wrapped assets bridged over from Ethereum. We don't need to read any metadata at this stage. That said, I guess a metadata mutator is not relevant to this PR, so I can cut another one.

[girazoki]

Yeah same thing, I could leave the mutators out of this PR too and leave the inspectors only.

[girazoki]

@shawntabrizi is there an option we can make parts of the pallet-assets storage public, either through traits or through a getter? We were thinking about assigning specific contract addresses to existing assets based on their Asset Id but we need to know if such An AssetId exists in the first place

[shawntabrizi]

Yup I am happy with this PR.

[shawntabrizi]

@thiolliere can you also review?

I dont see much reason for the audit, as it is just a code refactor. i don't see any real underlying changes.

[gui1117]

I feel like those fungibles metadata and fungibles approvals only make sense for fungibles, thus they could depend on fungibles inspect and this simplifies their generics.

WDYT ?

Apart from that, looks good to me

[girazoki]

Made them dependent on Fungibles, that leaves the traits only with AccountId as generics

[shawntabrizi]

bot merge

[ghost]

Trying merge.