blockjob: properly track blockcopy xml changes on disk
    
    We were not directly saving the domain XML to file after starting
    or finishing a blockcopy.  Without the startup write, a libvirtd
    restart in the middle of a copy job would forget that the job was
    underway.  Then at pivot, we were indirectly writing new XML in
    reaction to events that occur as we stop and restart the guest CPUs.
    But there was a race: since pivot is an async action, it is possible
    that libvirtd is restarted before the pivot completes, so if XML
    changes during the event, that change was not written.  The original
    blockcopy code cleared out the <mirror> element prior to restarting
    the CPUs, but this is also a race, observed if a user does an async
    pivot and a dumpxml before the event occurs.  Furthermore, this race
    will interfere with active commit in a future patch, because that
    code will rely on the <mirror> element at the time of the qemu event
    to determine whether to inform the user of a normal commit or an
    active commit.
    
    Fix things by saving state any time we modify live XML, while
    delaying XML disk modifications until after the event completes.  We
    still need a to teach libvirtd restarts to examine all existing
    <mirror> elements to see if the job completed in the meantime (that
    is, if libvirtd misses the event, the updated state still needs to be
    updated in live XML), but that will be a later patch, in part because
    we also need to to start taking advantage of newer qemu's ability to
    keep the job around after completion rather than the current usage
    where the job disappears both on error and on success.
    
    * src/qemu/qemu_driver.c (qemuDomainBlockCopy): Track XML change
    on disk.
    (qemuDomainBlockJobImpl, qemuDomainBlockPivot): Move job-end XML
    rewrites...
    * src/qemu/qemu_process.c (qemuProcessHandleBlockJob): ...here.
    
    Signed-off-by: Eric Blake <eblake@redhat.com>