Various binaries are statically linking to libvirt_util.la and
other intermediate libraries we build. These intermediate libs
all get built into the main libvirt.so shared library eventually,
so we can dynamically link to that instead and reduce the on disk
footprint.

In libvirt-daemon RPM:

            virtlockd: 1.6 MB -> 153 KB
             virtlogd: 1.6 MB -> 157 KB
     libvirt_iohelper: 937 KB -> 23 KB

In libvirt-daemon-driver-network RPM:

 libvirt_leaseshelper: 940 KB -> 26 KB

In libvirt-daemon-driver-storage-core RPM:

   libvirt_parthelper: 926 KB -> 21 KB

IOW, about 5.6 MB total space saving in a build done on Fedora 30
x86_64 architecture.
Reviewed-by: NJán Tomko <jtomko@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

Vim has trouble figuring out the filetype automatically because
the name doesn't follow existing conventions; annotations like
the ones we already have in Makefile.ci help it out.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

We need here libiscsi for the storgae pool backend.
For the iscsi-direct storage pool, only checkPool and refreshPool should
be necessary for basic support.
The pool is state-less and just need the informations within the volume
to work.
Signed-off-by: NClementine Hayat <clem@lse.epita.fr>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Introducing the pool as a noop. Integration inside the build
system. Implementation will be in the following commits.
Signed-off-by: NClementine Hayat <clem@lse.epita.fr>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

The storage file drivers are currently loaded as a side effect of
loading the storage driver. This is a bogus dependancy because the
storage file code has no interaction with the storage drivers, and
even ultimately be running in a completely separate daemon.
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

The storage file code needs to be run in the hypervisor drivers, while
the storage backend code needs to be run in the storage driver. Split
the source code as a preparatory step for creating separate loadable
modules.
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

The storage file code needs to be run in the hypervisor drivers, while
the storage backend code needs to be run in the storage driver. Split
the source code as a preparatory step for creating separate loadable
modules.
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>