proveAttachment only checks for existence of an attachment using just the digest and the legacy attachment storage format (base.AttPrefix + digest).

This breaks replication of attachments stored in the new format, at least for ISGR, when the attachment already exists on the remote peer.

Sample failing use case:

1. ISGR replication between SG 3.0.x and SG 2.8.x. Can be running in any configuration that replicates data from 3.0.x to 2.8.x (pull from 2.8.x, or push from 3.0.x)
2. Create a document with an attachment on 3.0.x. This will replicate successfully (as the attachment doesn't exist on 2.8.x, and so won't try to proveAttachment)
3. Create another document with the same attachment on 3.0.x. This will be stored in the new format on 3.0.x. Since the attachment already exists for that digest on 2.8.x, 2.8.x will send a proveAttachment request with just the digest
4. SG 3.0.x will look for the attachment in the old format and not find it, and then return "attachment not found".
5. SG 2.8.x doesn't fall back to getAttachment for "attachment not found" - it only falls back on NoBlipHandlerError
6. This results in a fatal error and the revision isn't replicated.

There are a few possible fixes here:
a. Have 3.0.x return NoBlipHandlerError when receiving a proveAttachment request from a replication using BlipCBMobileReplicationV2. Legacy peers will then fall through to getAttachment.
b. Have the 3.0.x proveAttachment code perform the same docID lookup that getAttachment is doing (using the docID in allowedAttachments, since legacy clients won't include it in the proveAttachments message)
c. Have 2.8.x recognize "attachment not found" and fall through to getAttachment.

I think (b) would be the preferred option, but it needs additional testing to ensure it works as expected.