qemu: fixing auto-detecting binary in domain capabilities
qemu: fixing auto-detecting binary in domain capabilities

The virConnectGetDomainCapabilities API accepts either a binary path
to the emulator, or desired guest arch. If guest arch is not given,
then the host arch is assumed.

In the case where the binary is not given, the code tried to find the
emulator binary in the existing list of cached emulator capabilities.
This is not valid since we switched to lazy population of the cache in:

  commit 3dd91af01f30c5bda6328454ef49f3afece755d6
  Author: Daniel P. Berrangé <bb938cf255e055ff3507f2627d214e8e62118fcf@redhat.com>
  Date:   Mon Dec 2 13:04:26 2019 +0000

    qemu: stop creating capabilities at driver startup

As a result of this change, if there are no persistent guests defined
using the requested guest architecture, virConnectGetDomainCapabilities
will fail to find an emulator binary.

The solution is to stop relying on the cached capabilities to find the
binary and instead use the same logic we use to pick default a binary
per arch when populating capabilities.

Tested-by: Boris Fiuczynski <2648abdd55bfebf313fd324b464b047e6eea300e@linux.ibm.com>
Tested-by: Richard W.M. Jones <d9c0c1814229c9d7f78a7e860ff9791c82a22dba@redhat.com>
Reviewed-by: Michal Privoznik <83d82aaba2eed257f4814b0c239c260c4caaadf0@redhat.com>
Signed-off-by: Daniel P. Berrangé <bb938cf255e055ff3507f2627d214e8e62118fcf@redhat.com>

nertpinx/libvirt,jfehlig/libvirt,jardasgit/libvirt,libvirt/libvirt,fabianfreyer/libvirt,fabianfreyer/libvirt,nertpinx/libvirt,zippy2/libvirt,jardasgit/libvirt,fabianfreyer/libvirt,zippy2/libvirt,crobinso/libvirt,jardasgit/libvirt,olafhering/libvirt,libvirt/libvirt,jfehlig/libvirt,jfehlig/libvirt,nertpinx/libvirt,fabianfreyer/libvirt,fabianfreyer/libvirt,nertpinx/libvirt,zippy2/libvirt,jardasgit/libvirt,crobinso/libvirt,crobinso/libvirt,olafhering/libvirt,libvirt/libvirt,crobinso/libvirt,zippy2/libvirt,olafhering/libvirt,libvirt/libvirt,nertpinx/libvirt,olafhering/libvirt,jardasgit/libvirt,jfehlig/libvirt