Tombstones

[mistermoe]

When a record is deleted via RecordsDelete, the initial RecordsWrite is kept as a tombstone in addition
to the RecordsDelete message. The data associated to that initial RecordsWrite is deleted. If a record was written
and deleted before it ever got to dwn-server, we end up in a situation where we still need to process the tombstone
so that we can process the RecordsDelete. This can and does happen when syncing.

This PR introduces the ability to process RecordsWrite messages with no associated data.

[frankhinek]

Although we’re planning to discuss the trade offs of this approach tomorrow, since we’ve got to get this bug fix in before any conclusion to that discussion, we should include a test that passes because a subsequent RecordsWrite (an overwrite) that mutates a descriptor property (but not data) takes the synchronizePrunedInitialRecordsWrite() path. Perhaps a Sinon spy would work?

[michaelneale]

does this change anything around data retention - like is there a case where record could have been deleted on client and never made it to server but now does with a tombstone? that is my only feedback.

[frankhinek]

As discussed with @mistermoe and @thehenrytsai this afternoon:

• introduce a fix for the sync issue as implemented in this PR
• quickly follow with one of the two following changes:
  1. dwn-sdk-js change would be to modify the synchronizePrunedInitialRecordsWrite() method signature to take as input a RecordsWrite message with no associated data && a RecordsDelete.
  2. dwn-server and web5-js modification to introduce a new endpoint / RPC handler that is dedicated to sync so that RecordsWrite overwrites that mutate properties other than data don't flow through synchronizePrunedInitialRecordsWrite() unintentionally.

Created Issue #32 to track.

[mistermoe]

does this change anything around data retention - like is there a case where record could have been deleted on client and never made it to server but now does with a tombstone? that is my only feedback.

@michaelneale currently, anytime web5-js encounters a sync error it halts syncing. after this PR is merged, dwn-servers are redeployed, and web5-js PR is merged, (assuming people version bump) people who are encountering this error won't halt anymore and everything should work as expected.