Support CBL clients that don't increment revpos when attachment body changes

CBL clients using delta sync are incorrectly not incrementing an attachment's revpos when the attachment contents change when using delta sync.

This results in the attachment not being updated when the revision is pushed to Sync Gateway - delta sync merges the incoming _attachment property with the previous one, resulting in the older revpos value. Since the revpos is old, Sync Gateway assumes it already knows about this attachment and doesn't update the _attachment metadata.

Here's an example. This is the initial payload sent by CBL for the first version of the attachment:

    {"type":"task","complete":false,"task":"Task1","taskList":{"owner":"user1","id":"user1.C2A33691-EE4D-497D-B6E4-DAB5424998BE"},"createdAt":"2022-03-03T19:08:25.651Z",

    "image":{"length":2051240,"digest":"sha1-yNrLH9jxGSDhenJZvYSOUXWgnhQ=","content_type":"image/jpeg","@type":"blob"},"

    _attachments":{"blob_/image":{"length":2051240,"digest":"sha1-yNrLH9jxGSDhenJZvYSOUXWgnhQ=","content_type":"image/jpeg","stub":true,"revpos":4}}}

The attachment is updated on the client, and CBL sends this delta:

  {"_attachments":{"blob_/image":{"content_type":"image/jpg","digest":"sha1-UzFeXdWAt/GoJ4y0ak0IH82sJg0=","length":500554}},

    "image":{"content_type":"image/jpg","digest":"sha1-UzFeXdWAt/GoJ4y0ak0IH82sJg0=","length":500554}}

Since revpos isn't included in the delta, the _attachments content doesn't get updated on the SG side, resulting in this:

{"_attachments":{"blob_/image":{"content_type":"image/jpeg","digest":"sha1-yNrLH9jxGSDhenJZvYSOUXWgnhQ=","length":2051240,"revpos":4,"stub":true}},"_id":"-oyDVcP3l1qOsuZixcXap9W","_rev":"5-450d033bdaca325ce8edd0e974b9d8426f3630a4","complete":false,"createdAt":"2022-03-03T19:08:25.651Z","image":{"@type":"blob","content_type":"image/jpg","digest":"sha1-UzFeXdWAt/GoJ4y0ak0IH82sJg0=","length":500554},"task":"Task1","taskList":{"id":"user1.C2A33691-EE4D-497D-B6E4-DAB5424998BE","owner":"user1"},"type":"task"}

Prior to Sync Gateway 3.0 this worked. I believe this is due to revpos being computed conservatively prior to 3.0, as a side effect of shared attachment storage. That's been fixed in 3.0, but has exposed this existing CBL issue.

There will be a CBL fix to correct the revpos value, but we'd like to explore whether Sync Gateway can also be more defensive in this case, to provide backward compatibility with non-patched CBL clients. In addition to the revpos check, evaluate whether we can check for differences in attachment digest, and override the client's revpos value when that differs (to set the revpos to the current rev generation).