CardDAV: rewrite vCard 4.0 in CardDAV GET

[rsto]

This works around a bug that had caused Cyrus to write bogus version 4.0 vCards to disk. The issue was that embedded binary data in version 4.0 must be encoded as a data: URI, but it was written as a version 3.0 b-encoded value. The bug is fixed in b8a879c

This patch changes CardDAV GET to always rewrite a version 4.0 vCard before sending the response to the client, even if the vCard already is having version 4.0. As a result, clients get correctly encoded property values for both v3.0 and v4.0.

[ksmurchison]

LGTM assuming that CI passes

[elliefm]

@rsto I think we should be backporting this one (and the fix in #4877) to the stable branches, yeah? But I'm not sure since you've tagged it do-not-merge. Skimming old release notes, it looks like we've had some kind of vCard 4.0 support since ~3.6, but I'm not sure if the bug dates back that far or was recent.

[rsto]

@elliefm We should backport PR4877. I just created #4881 to do so, the patch didn't apply cleanly so I had to pull in another commit for backporting. The JMAPContacts and Carddav tests now pass for me locally, let's see what CI says about it.

The bug got introduced in 2018 in afc3527

I tagged #4880 as Do-Not-Merge because it is more a workaround than a final solution. A real solution would be to fix the data on-disk, but we haven't come up with tooling for that, yet.
Note that all this only is relevant for installations that already use the JMAP Contacts API, which is experimental and its data model will change significantly when the RFC standards are published at IETF.