As we work on graphsync CBOR protocol 2.0, we are moving the metadata out of an extension and into the core protocol. Simultaneously, it's a good moment to make some additions and optimizations to the structure.

My proposed new structure is as follows:

type GraphSyncLinkAction enum {
   # Present means the linked block was present on this machine, and is included in this message
   | Present
   # DuplicateNotSent means the linked block was present on this machine, but I am not sending it (most likely duplicate)
   | DuplicateNotSent
   # Missing means I did not have the linked block, so I skipped over this part of the traversal
   | Missing
   # DuplicateDAGSkipped means the DAG with this link points toward has already been traversed entirely in the course of this request
   # so I am skipping over it entirely
   | DuplicateDAGSkipped
} representation int

type GraphSyncMetadatum struct {
  link         &Any
  action    GraphSyncLinkAction
} representation tuple

type GraphSyncMetadata [GraphsyncMetadatum]

Major changes:

1. Representation tuple rather than map for each Metadatum
2. Changing blockPresent bool to an action enum.

Downgrade actions are as follows:

• Present -> blockPresent = true
• DuplicateNotSent -> blockPresent = true (this is a bit counterintuitive, but currently, we communicate that a single block was a duplicate simply by not including it in the blocks list elsewhere in the message. when we do this, blockPresent is still true cause I as a server did have the block, I just believe I already sent it to you)
• Missing -> blockPresent = false
• DuplicateDAGSkipped -> no clear downgrade action, meaning we simply can't support it for 1.0 protocol requests. Adding this function would require writing new software anyway, so my suggestion is we don't implement it on the responder immediately.

Upgrade actions are as follows:
blockPresent = true + block in message -> Present
blockPresent = true + block not in message -> DuplicateNotSent
blockPresent = false -> Missing

Handling DuplicateDAGSkipped on the requestor -> I will write this software -- there's some refactors of the async loading process I've needed to do for a while.

Supporiting DuplicateDAGSkipped on the responder would require tracking protocols farther into the responder and I'm not sure how we should do that.