Create a more complete demo-nft-module with collections, metadata uri, freezing, updates, supply

[dubbelosix]

Overview

demo-nft-module has been enhanced to include the concept of Collections, NFTs and calls to create, modify, freeze collections and NFTs and to transfer NFTs. Existing demo-nft-module has been moved to simple-nft-module since it still serves as a very simply and easy to understand tutorial. simple-nft-module focuses more on the sovereign-sdk usage aspects, while demo-nft-module aims to be a more ready implementation to plug-n-play and customize if necessary

Changes

• demo-nft-module has no genesis
• README.md added to explain the basic concepts, calls provided as well as example sov-cli commands to interact with the demo-nft-module on a running rollup
• demo-nft-module has also been added to runtime, so it would be a permanent module

Further changes

The offchain component for indexing the NFTs into an offchain store will be part of a second PR.

Test cases added

• Create Collection
• Mint NFT to created collection
• Mint NFT to non-existent collection
• Update a collection
• Freeze a non existent collection
• Freeze Collection
• Update collection uri for frozen collection
  • assert that the collection uri hasn't been changed
  • assert that supply hasn't been modified
• Supply change after minting an NFT to a Collection
• Minting to a Frozen Collection
  • ensure supply hasn't changed
• Transferring an NFT from a non-owner address
• Transferring NFT with non-existent token id
• Update NFT token_uri
• Freeze NFT
• Update NFT token uri for frozen NFT

[codecov]

Codecov Report

Merging #850 (da2a165) into nightly (62ae7dc) will increase coverage by 0.4%.
The diff coverage is 92.2%.

Files Changed	Coverage Δ
...module-implementations/sov-nft-module/src/query.rs	71.4% <71.4%> (ø)
...dule-implementations/sov-nft-module/src/address.rs	75.0% <75.0%> (ø)
...m/module-implementations/sov-nft-module/src/nft.rs	88.4% <88.4%> (ø)
...e-implementations/sov-nft-module/src/collection.rs	92.2% <92.2%> (ø)
.../module-implementations/sov-nft-module/src/call.rs	97.2% <97.2%> (ø)
...m/module-implementations/sov-nft-module/src/lib.rs	98.2% <98.2%> (ø)
...module-implementations/sov-nft-module/src/utils.rs	100.0% <100.0%> (ø)
...-system/sov-modules-macros/src/dispatch/genesis.rs	100.0% <100.0%> (ø)
module-system/sov-modules-macros/src/lib.rs	100.0% <100.0%> (ø)
module-system/sov-modules-macros/src/new_types.rs	100.0% <100.0%> (ø)

... and 2 files with indirect coverage changes

[preston-evans98]

Looks really good overall. Left a couple of notes about type safety, but just one overall question - how would someone use this to create an NFT drop? It looks like in the current implementation the collection creator has to sign on every individual mint - maybe we should change the interface to have mint which can be called by other modules in addition to the current function mint_from_eoa? The bank follows that pattern.

[dubbelosix]

Looks really good overall. Left a couple of notes about type safety, but just one overall question - how would someone use this to create an NFT drop? It looks like in the current implementation the collection creator has to sign on every individual mint - maybe we should change the interface to have mint which can be called by other modules in addition to the current function mint_from_eoa? The bank follows that pattern.

yeah, I agree. we can follow the same pattern, so that way a creator can mint to addresses directly, or the mint can also be created in conjunction with a token that exists in the Bank (will be doing this in a different PR to not make this one too large)