feat: store metadata in IPLD CBOR format

[alanshaw]

This PR adds a storeMetadata method that allows for storing NFT metadata encoded using IPLD CBOR.

It takes an Object - the metadata to persist. It recursively inspects the object to see if there are any Files or Blobs and when it find them it calls storeBlob/storeDirectory and replaces them with a CID.

The result is an object that we can pass to js-dag-cbor for encoding.

I need to figure out how to store the encoded data. I've just passed it to storeBlob, which gives us back a CID with the RAW codec (since it's small enough and we specify v1 CIDs, giving us raw leaves). In the code I'm taking this RAW CID and re-encoding it to be CBOR. I thought this would work but it looks like the blockstore is still keyed on CID not multihash...

The plan was to then be able to view this on the gateway: ipfs/kubo#8037

I'm using this code to test (runnable in Node.js):

import fs from 'fs'
import { NFTStorage, File } from '../../src/lib.js'

const endpoint = 'https://staging.nft.storage'
const token = 'xxx'

async function main() {
  const store = new NFTStorage({ endpoint, token })
  const data = await fs.promises.readFile('lost-dog.jpg')
  const cid = await store.storeMetadata({
    name: 'My NFT',
    image: new File([data], 'lost-dog.jpg')
  })
  console.log({ cid })
}
main()

[Gozala]

This is cool! I was thinking of doing something slightly different that is:

1. Create a content bundle like a car file so that
2. It would inline all the files
3. A JSON serialization written as metadata.json
4. A dag-cbor with pointers to all of the above (kind of like you do here)

Then we could turn return value into:

{
   cid: CIDString // CID to the cbor with links to everything
   jsonURL: URL // ipfs://${cid} URL to a metadata.json
   data: JSON // JSON that written as `metadata.json`
}

That way:

1. Single NFT will correspond to single dag-cbor with links to all the relevant files and encoding al data.
2. We don't force IPLD, JSON representation of it is still there.
3. We do also proactively make things IPLD native, and lay the upgrade path to folks that want to.
4. Since we have all the data locally anyway, we include that in data so that URLs for all the files can be pulled out without another roundtrip.

[alanshaw]

closing in favour of #56