allow minting directly to nft

[bmacer]

This is basic implementation but some missing pieces

• need to add tests:
• mint to nft works,
• mint to nft fails if nft doesn't exist,
• mint to non-owned nft results in pending state
• other tests?
• currently i think minting to a non-owned nft with resources will leave each resource in pending state, which is likely undesirable. we want the resources accepted on minted adds. two possible solutions: (1) implement an auto-accept right after the resource add inside of the mint [con: bunch of events, maybe more weight], (2) add an during_mint parameter to resource_add, which would override the requirement for sender to equal owner. i'd vote for option 2.

[bmacer]

Fixed the last issue, where ALICE mints an NFT with resources to a BOB-owned NFT. The issue is that these resources would all be in a pending state (because BOB is not the rootowner of the collection). Not ideal, the resources should be auto-accepted (after all the NFT itself is already in a pending state, no need to require an accept for every resource in addition to the NFT itself (again only in the case of a mint_nft extrinsic.

[bmacer]

Fixes #173

[HashWarlock]

We should create a separate function for this instead.

[ilionic]

Works well, thank you.

[ilionic]

@HashWarlock can you please clarify about separate function.

[HashWarlock]

@HashWarlock can you please clarify about separate function.

We should have a function that mints an NFT to an owner and separate function to mint to an NFT. This keeps from one function doing too much.

[bmacer]

@HashWarlock can you please clarify about separate function.

We should have a function that mints an NFT to an owner and separate function to mint to an NFT. This keeps from one function doing too much.

I think I disagree with this making things too complicated, but will trust your judgment. Working on decoupling the enum and implementing fix.

[bmacer]

after a mighty long struggle with decoupling efforts, i've come to agree that decoupling is best. @HashWarlock can you take a peak again when you get a chance?

[ilionic]

isn't collection_id redundant now, because it's already part of owner tuple?

[bmacer]

No, owner is the identifier of the NFT that will own the new NFT, collection_id is where the NFT should be minted into. I'd expect we don't want to require these collections be the same.