add_drive: Introduce 'cachemode' parameter to control drive caching.

This commit adds an optional 'cachemode' parameter to the 'add_drive'
API to control caching.  This corresponds approximately to the
'-drive ...,cache=' parameter in qemu, but the choices are much more
restrictive, just 'writeback' or 'unsafe', for reasons outlined below.

The caching modes supported by recent QEMU are:

  writeback:
   - Reports data writes completed when data is present in the host
     page cache.
     Only safe provided guest correctly issues flush operations.

  writethrough:
   - Reports data writes completed only when each write has been
     flushed to disk.  Performance is reported as not good.

  none:
   - Uses O_DIRECT (avoids all interaction with host cache), but does
     not ensure every write is flushed to disk.
     Only safe provided guest correctly issues flush operations.

  directsync:
   - Uses O_DIRECT (avoids all interaction with host cache), and
     ensures every write has been flushed to disk.

  unsafe:
   - No special handling.

Since the libguestfs appliance kernel always issues flush operations
(eg. for filesystem journalling and for sync) the following modes can
be ignored: 'directsync', 'writethrough'.

That leaves 'writeback', 'none' and 'unsafe'.  However 'none' is both
a constant source of pain (RHBZ#994517), is inefficient because it
doesn't use the host cache, and does not give us any safety guarantees
over and above 'writeback'.  Therefore we should ignore 'none'.

This leaves 'writeback' (safe) and 'unsafe' (fast, useful for scratch
disks), which is what we implement in this patch.

Note that the previous behaviour was to use 'none' if possible, else
to use 'writeback'.  The new behaviour is to use 'writeback' only
which is (in safety terms) equivalent to 'none', and also faster and
less painful (RHBZ#994517).

This patch also allows you to specify a cache mode for network drives
which also previously defaulted to 'writeback'.

There is a considerable performance benefit to using unsafe (for
scratch disks only, of course).  The C API tests only use scratch
disks (since they are just tests, the final state of the disk doesn't
matter), and this decreases total run time from 202 seconds to 163
seconds, about 25% faster.

(cherry picked from commit 749e947bb0103f19feda0f29b6cbbf3cbfa350da)
drives: Ensure all scratch drives use cachemode "unsafe".

They are _scratch_ drives so any data on them doesn't matter and can
be reconstructed in the event of a host system crash.

(cherry picked from commit 96cd7fcecb031bfe6baa49addfb026ae988fb7c1)
sparsify: Use cachemode "unsafe" for the overlay disk.

(cherry picked from commit f3a9c9f867bed178d1aabf9675955f633bf3069a)
rescue: Use cachemode "unsafe" for the virt-rescue --scratch option.

(cherry picked from commit 3f0748f1fc64e42517c0d4535c27b1f32da86023)
RHEL 7: Emphasize libguestfs-winsupport package (RHBZ#627468).

This RHEL-only patch changes the error messages when the
inspection code cannot find an operating system inside the guest
image.  For a Windows guest this may happen because the user has not
installed the separate 'libguestfs-winsupport' package.  Therefore we
emphasize that the user may need to install this package.

Notes:

(1) In RHEL there are two pieces of inspection code, the old Perl code
(deprecated upstream) and the new C core inspection API.  Therefore
this patch has to touch two places with essentially the same change.

(2) This patch doesn't try to be clever and detect if it was a Windows
guest.  This should reduce the chance of failure.

Output from (Perl) virt-inspector now looks like this:

 $ virt-inspector disk.img
 No operating system could be detected inside this disk image.

 This may be because the file is not a disk image, or is not a virtual machine
 image, or because the OS type is not understood by virt-inspector.

 If you feel this is an error, please file a bug report including as much
 information about the disk image as possible.

 RHEL notice
 -------------
 libguestfs will return this error for Microsoft Windows guests if the
 separate 'libguestfs-winsupport' package is not installed. If the
 guest is running Microsoft Windows, please try again after installing
 'libguestfs-winsupport'.

Output from guestfish (ie. C core inspection API) now looks like this:

 $ guestfish -i disk.img
 guestfish: no operating system was found on this disk

 RHEL notice
 -------------
 libguestfs will return this error for Microsoft Windows guests if the
 separate 'libguestfs-winsupport' package is not installed. If the
 guest is running Microsoft Windows, please try again after installing
 'libguestfs-winsupport'.
RHEL 7: Remove libguestfs live (RHBZ#798980).

This isn't supported in RHEL 7.
RHEL 7: Exclude iptables from the appliance (RHBZ#858648).
RHEL 7: Ignore /etc/release if /etc/redhat-release exists (RHBZ#873219).

If the user has created /etc/release on a RHEL machine, don't
mis-detect the OS as NetBSD.
RHEL 7: Remove 9p APIs from RHEL (RHBZ#921710).
RHEL 7: Disable unsupported remote drive protocols (RHBZ#962113).

This disables support for unsupported remote drive protocols:

 * ftp
 * ftps
 * http
 * https
 * tftp
 * gluster
 * iscsi
 * rbd
 * sheepdog
 * ssh

Note 'nbd' is not disabled, and of course 'file' works.

We hope to gradually add some of these back over the lifetime of RHEL 7.