Updating CTL version, fixing for breaking changes

[rynoV]

Closes #37 and #30

Changes:

• Use updated CIP25 metadata
• Use updated contract initialization Reimplement contract configuration interface. Allow parallel Contract execution Plutonomicon/cardano-transaction-lib#731
• Stop using Contract's extraConfig
• Update getWalletBalance so it doesn't cause a major error, see e04e2f2 and https://github.com/mlabs-haskell/nft-marketplace/tree/calum/contracts-updates

TODO:

• Move away from extraConfig
  • This feature of CTL is going to be removed eventually, I think I may as well refactor while I'm doing this migration
  • I tried a custom monad stack here, it's not much better than just passing an extra parameter to the contracts that need the projectId
    • We could make it nicer by implementing our own liftX functions to make interoperating with all of CTL's Contract functions easier, but I don't think it's worth it right now
• Make sure to properly reuse contract environment (websocket connections, etc.)
  • This PR is on par with master in terms of the number of websocket connections
  • It might be possible to refactor so that the contract environment is reused across contract calls, but I think that's premature optimization at this point
• Hopefully integrate fixes for Invalid frame header Plutonomicon/cardano-transaction-lib#803 because we're also seeing the issue described there
  • The issue isn't breaking the app though, so we could merge without it

[samuelWilliams99]

I assume merging this will mean we'll need to update the ctl ref in the monorepo as well?

[samuelWilliams99]

This seems like an API change? will the frontend handle this correctly?

[rynoV]

You're right, forgot about this, I'll make the update in this PR

[rynoV]

The description and name aren't actually parsed from the metadata, they're retrieved from the database. However the image field is parsed from the metadata, and that format changed from an array to a string, so I updated the parsing for it. According to the cip25 standard the image field can be a string or an array, so I made the parsing handle both possibilities, and this also means the nfts minted before this update are still useable

[rynoV]

I assume merging this will mean we'll need to update the ctl ref in the monorepo as well?

It would probably be for the best. Maybe we should merge into some kind of staging branch instead?

[samuelWilliams99]

Perhaps, but it's a relatively uncommon change, I think it's fine to just pr both of them
the subrepo should be commit locked anyway

[rynoV]

Tested 866fadd:

• cnft: https://testnet.cardanoscan.io/transaction/5e91f15855627d1864f8816202a2ed277bcd1c67ab0a263cb44aaa8379d0e61d
• sgnft: https://testnet.cardanoscan.io/transaction/02804e732c6244a564236f536fb5a070a87bbb79b637dc8f109c7892551446aa
• purchase: https://testnet.cardanoscan.io/transaction/1b1b9919dcfd7a10cde0c8ac2482316cf6a13405748f7589f3817cd3d00b1fd5

[samuelWilliams99]

I believe in the CIP standard, long strings are split into arrays, is this how the image field works? or is each element intended to be a separate image?

[rynoV]

For metadata created by us, we shouldn't be getting any images which are long strings split up, unless we change the length of our image value.

We could use CTL's cip25 modules to parse this and that should handle long strings being split into arrays, but then the NFTs minted previously would no longer be valid. I guess it's okay though, the old nfts are just for testing anyways

[samuelWilliams99]

We'll need to support arbitrary cNFTs that adhere to the standard, as we won't always be the ones minting them. In future, artists will want a way to take their existing nft and import it to the protocol.

[samuelWilliams99]

#42