qemu: Fix crash hot plugging luks volume
    
    https://bugzilla.redhat.com/show_bug.cgi?id=1367259
    
    Crash occurs because 'secrets' is being dereferenced in call:
    
            if (qemuDomainSecretSetup(conn, priv, secinfo, disk->info.alias,
                                      VIR_SECRET_USAGE_TYPE_VOLUME, NULL,
                                      &src->encryption->secrets[0]->seclookupdef,
                                      true) < 0)
    
    (gdb) p *src->encryption
    $1 = {format = 2, nsecrets = 0, secrets = 0x0, encinfo = {cipher_size = 0,
        cipher_name = 0x0, cipher_mode = 0x0, cipher_hash = 0x0, ivgen_name = 0x0,
        ivgen_hash = 0x0}}
    (gdb) bt
        priv=priv@entry=0x7fffc03be160, disk=disk@entry=0x7fffb4002ae0)
        at qemu/qemu_domain.c:1087
        disk=0x7fffb4002ae0, vm=0x7fffc03a2580, driver=0x7fffc02ca390,
        conn=0x7fffb00009a0) at qemu/qemu_hotplug.c:355
    
    Upon entry to qemuDomainAttachVirtioDiskDevice, src->encryption points
    at a valid 'secret' buffer w/ nsecrets == 1; however, the call to
    qemuDomainDetermineDiskChain will call virStorageFileGetMetadata
    and eventually virStorageFileGetMetadataInternal where the src->encryption
    was overwritten when probing the volume.
    
    Commit id 'a48c7141' added code to virStorageFileGetMetadataInternal
    to determine if the disk/volume would use/need encryption and allocated
    a meta->encryption. This overwrote an existing encryption buffer
    already provided by the XML
    
    This patch adds a check for meta->encryption already present before
    just allocating and overwriting an existing buffer. It then checks the
    existing encryption data to ensure the XML provided format for the
    disk matches the expected format read from the disk and errors if there
    is a mismatch.