Feature/minting lazy

[boyswan]

This decouples the core and lazy minting functionality, and instead provides 2 traits Minting & MintingLazy to allow the user to choose their desired implementation.

I propose some small changes to the trait methods to allow consistency between core/lazy and provide a clearer api.

Minting (Ownable, Non-payable)

pub trait Minting {
    fn mint(&mut self, to: AccountId) -> Result<Id>;
    fn mint_many(&mut self, to: AccountId, mint_amount: u64) -> Result<(Id, Id)>;
    fn assign_metadata(&mut self, token_id: Id, metadata: String) -> Result<()>;
    fn max_supply(&self) -> u64;
    fn token_uri(&self, token_id: u64) -> Result<String>;
} 

MintingLazy (Payable)

pub trait MintingLazy {
    fn mint(&mut self) -> Result<()>;
    fn mint_many(&mut self, mint_amount: u64) -> Result<()>;
    fn price(&self) -> Balance;
    fn max_supply(&self) -> u64;
    fn token_uri(&self, token_id: u64) -> Result<String>;
} 

Other than minting methods, the only differences between the implementations are Minting having assing_metadata as this is not a needed for lazy, and price is only available in MintingLazy.

Other updates include:

• Return Id and (Id, Id) (id range) for the Minting implementation for use cross-contract logic.
• Decouple assign_metadata from minting logic. This provides greater flexibility. Current implementation only caters for single-mint-with-metadata.
• Moving common minting behaviour to underlying internal trait.
• Create equippable-lazy example, which is used in the JS tests.
• Remove unwraps in token_uri

I have also moved the minting tests into the minting crate, and split them between core & lazy.

[steven2308]

This is a great change!
I just left a couple minor doubts to to my lack of knowledge on ink!.

[steven2308]

This seems very opinionated. Can implementers override it in case they want a different logic?

[boyswan]

So I left the existing logic intact but just refactored away some potentially unsafe code. Maybe @Maar-io can answer this better than me!

[Maar-io]

Any of the default fn can be overridden. Just check how Evens are handled.

[boyswan]

Do we think the from_attribute part of the logic is clear enough? It confused me a little as it could be completely different from the metadata the user has assigned to a token, which is what the user is expecting to return.

Would it not be clearer to return None if their metadata has not been set, and then it's up to the user to handle this with custom logic (such as what's in from_attribute)?

[Maar-io]

we do not need to use attributes at all. They come from metadata trait but if it is confusing, better to remove it and use contract's storage

[Maar-io]

Would it make sense to move rmrk_example_equippable::tests: into equippable crate?

[Maar-io]

LGTM

I'll move it to ink 4.0 soon and take a deeper look

[boyswan]

Would it make sense to move rmrk_example_equippable::tests: into equippable crate?

Yeah definitely, will make a separate PR for it though and keep this one to minting