New API: add-drive-scratch.

This adds a temporary scratch drive to the handle.

(cherry picked from commit 1b11a83d5248511abbf86775601eb6e25a36c1ee)
(cherry picked from commit eaffd8105fcd164616aad47cea2b2bf56686acfa)
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)
(cherry picked from commit c7304d0c8ebe38bc90547f149026ca279a4e7c46)
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)
(cherry picked from commit 053061f66f79d21bb48d089717a171470e05e47e)
sparsify: Use cachemode "unsafe" for the overlay disk.

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

(cherry picked from commit 3f0748f1fc64e42517c0d4535c27b1f32da86023)
(cherry picked from commit 1e421afa988195bead6650c421d9752fed32b73f)
launch: direct: Always use cache=unsafe for the appliance.

The code to select writeback was redundant, because current
qemu always supports cache=unsafe.

(cherry picked from commit 011c9639267f5f1bfac41e664b2c57cc12deabf8)
(cherry picked from commit 5be3a863c57aa56677338b499c4d6774d6384c3d)