cbbackupmgr cloud rollback edge case causing truncation of Rift versioning space

When rolling back the Rift objects store data store we need to consider the implications of the fact that we must rollback onto a multipart upload part boundary.

Why is this an issue?
Imagine we have a case, where for some reason we want to rollback the whole data store (which can and does happen); since we are using Rift, and it has 4KB of versioning space at the front, we will inform the data store to truncate to 4KB. This works fine when truncating a file on disk, however, when we must rollback to a part boundary, this means the multipart uploader will rollback slightly further (in-fact, it will perform a complete rollback). The backup would resume and complete successfully; the bug exposes itself when attempting to restore. We try to read the data store, and we get an error stating the Rift index/data versions are diverging (depending on the data in the data store, you may be unlucky and have the first 4 bytes be the big endian representation of 1, the current Rift version, in which case you will get a checksum validation error during the restore).

How do we fix this issue?
Quite simply, we slightly modify the multipart uploaders 'Rollback' function signature to return (bool, error) instead of (errror). This boolean will state whether or not we were forced to rollback completely in which case we must re-populate the Rift object store data stores initial buffer with the 4KB versioning information.