Store upload/add shards as a Set.

[olizilla]

DynamoDB supports Sets!
https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWorks.NamingRulesDataTypes.html#HowItWorks.DataTypes.SetTypes

We can insert 1 upload doc per space+root, instead of unwrapping the shards array:

{ 
  space: DID, 
  root: CID, 
+ shards: Set<CID>
- shard: CID
- sk: `root#shard`
}

with the key

{ 
  partitionKey: `space`,
+ sortKey: `root` 
- sortKey: `sk` 
}

so we make root unique per space...

If an agent calls upload/add multiple times with the same root, we can use UpdateItem and specify that the shards set should be added to the existing item, preserving our existing "it's the union of all calls to upload/add semantics" while also avoiding opening us up to a single invocation expanding out to a large number of ops / records.

We can use UpdateItem as an upsert operation by specifying all the fields as:

UpdateItem: Edits an existing item's attributes, or adds a new item to the table if it does not already exist.

if we choose to support user metadata from an allowed list of additional nb properties then we can similarly treat that as a metadata map, and merge the keys where we see multiple invocations for the same root.

This change would pair nicely with a tweak to the ouput for upload/list where we would return the records as we store them, giving the caller a single record per root, with a shards array, to mirror the shape that they send them to us, rather than sending repeated rows per root#shard combo.

[olizilla]

it's not totally obvious what we should do with invocation and issuer... it has been suggested that we don't need to capture the issuer in the db... it's already in the invocation.

We could store invocations as a list here (preserving order, a set would not) and add to that property on each invocation.