Description of problem:

Right now, QMP active commit never rewrites metadata (well, except for the case in bug 1208566), even when it is collapsing more than one backing file in a single operation.  However, it would be useful to have a mode where the backing file can be rewritten as part of the commit.  That is, given a chain A <- B <- C, with contents:
   A 1111    # snapshot sees 1111
A<-B -22-    # snapshot sees 1221
B<-C --33    # guest sees 1233

and committing C into A, QMP currently keeps the chain intact.  If we complete the operation, we have:
   A 1233    # guest sees 1233, all is well
A<-B -22-    # no longer in use, so who cares
B<-C --33    # no longer in use, so who cares

But if we abort the operation after hitting sync, we have:
   A 1233    # snapshot sees 1233
A<-B -22-    # snapshot sees 1223, which never existed - we corrupted B
B<-C --33    # guest sees 1233

It's not nice to have a corrupt image in the chain; what would be nicer is to have the option to abort the active commit but simultaneously shorten the backing chain, by updating C to now directly point to A:

   A 1233    # snapshot sees 1233
A<-B -22-    # no longer in use, so who cares
A<-C --33    # guest sees 1233, and chain is accurate

This is related to bug 1208575: qemu-img commit defaults to a mode that preserves the backing chain, but merely resets the point in time that is represented by the backing chain.  At present, it lacks the ability to do an efficient commit across multiple files in a single shot (bug 1208555), but you can rebase C to be all changes since a point in time committed into A (qemu-img commit C, qemu-img commit B, qemu-img rebase -u -b A C), so that a later write of '4--4' gives us:
   A 1233    # snapshot sees 1233
A<-C 4--4    # guest sees 4234, C tracks all changes since chain rewrite

if QMP learns to empty the active file when aborting an active commit, but the active commit spans multiple files, then the backing chain MUST be rewritten to skip B.  Here's what happens if we don't:
   A 1233    # snapshot sees 1233
A<-B -22-    # corrupt
B<-C ----    # guest sees 1223 - guest is corrupt

[Note, however, that this bug is only about the state when active commit has reached sync.  We already know that during the active commit operation, that the destination file is neither at the old or new state, and aborting before sync won't impact the guest, but does screw up the chain:
   A 1231    # aborted after first 3, but not second, was committed - A no longer matches any real point in time
A<-B -22-    # for this particular abort, B still sees 1221; but aborting at other times could also lead to B being corrupt
B<-C --33    # guest is still safe with contents 1233
]

Version-Release number of selected component (if applicable):
still affects upstream 2.3

How reproducible:
100%

Steps to Reproduce:
1.
2.
3.

Actual results:
when aborting a multi-BDS commit when in sync, the active layer now depends on corrupted intermediate images.

Expected results:
rewrite the chain at the point of abort so the corrupted images are no longer part of the chain.  [Of course, if you abort _before_ things are in sync, then you are stuck with a corrupted chain, but dirty bitmaps might help track that issue, and retrying the commit until you DO reach sync can clean it up]

Additional info:
see also this thread: https://lists.gnu.org/archive/html/qemu-devel/2015-04/msg00276.html