Avoid content recovery sidecar altogether

[chibenwa]

Why ?

Today the S3 content recovery involves creating an extra S3 object for each mail. This makes it going from 1.5 object-per mail to 2.5 object per mail (accoutning for 50% body dedup) so a +66% in real life and +50% minimum.

We can shrink this by:

• using a s3 metadata onto the header blob
• generating a randon blobId to ensure headerBlobId <-> recovery metadata uniqueness and no rewrite
• likely hook a prefix for headers to ease listing

What I'd like to see is this out of CassandraMessageDAOV3 hidden by a real interface.

interface MessageContentSaver {
    Mono<Tuple2<BlobId, BlobId>> saveContent(byte[] headerBytes, ByteSource bodyByteSource);
}

Pros:

• Application of the S3 recovery policy would become a guice decision
• S3 recovery would be clearly isolated
• Easier to write our new recovery policy content saving
• Easier overrides of that critical code location in case of project objections.
• GC can be simplified as the sidecar object no longer need dedicated handling

[quantranhong1999]

apache#3153