RAID:  Disallow addition of RAID images while array is not in-sync

We cannot add images to a RAID array while it is not in-sync.  The
kernel will simply reject the table, saying:
	'rebuild' specified while array is not in-sync
Now we check to ensure the LV is in-sync before attempting image
additions.
cleanup:  Reduce indentation by short-circuiting function

By changing the conditional for resyncing mirrors with core-logs a
bit, we can short-circuit the rest of the function for that case
and reduce the amount of indenting in the rest of the function.

This cleanup will simplify future patches aimed at properly handling
the resync of RAID LVs.
cleanup:  Restructure code that handles mirror resyncing

When an LV is to be resynced, the metadata areas are cleared and the
LV is reactivated.  This is true for mirroring and will also be true
for RAID LVs.  We restructure the code in lvchange_resync() so that we
keep all the common steps necessary (validation of ability to resync,
deactivation, activation of meta/log devices, clearing of those devices,
etc) and place the code that will be divergent in separate functions:
	detach_metadata_devices()
	attach_metadata_devices()

The common steps will be processed on lists of metadata devices.  Before
RAID capability is added, this will simply be the mirror log device (if
found).

This patch lays the ground-work for adding resync of RAID LVs.
RAID:  Properly handle resync of RAID LVs

Issuing a 'lvchange --resync <VG>/<RAID_LV>' had no effect.  This is
because the code to handle RAID LVs was not present.  This patch adds
the code that will clear the metadata areas of RAID LVs - causing them
to resync upon activation.
vgchange: fix -aay to activate proper volumes

Using 'activation/auto_activation_volume_list = [ "vg/lvol1" ]'.

Before this patch:
  3 logical volume(s) in volume group "vg" now active
  LV    VG   Attr     LSize Pool Origin Data%  Move Log Copy%  Convert
  lvol0 vg   -wi----- 4.00m
  lvol1 vg   -wi-a--- 4.00m
  lvol2 vg   -wi-a--- 4.00m
  lvol3 vg   -wi-a--- 4.00m

(vg/lvol1 activated as it passes the list and all subsequent volumes too - wrong!)

With this patch:
  1 logical volume(s) in volume group "vg" now active
  LV    VG   Attr     LSize Pool Origin Data%  Move Log Copy%  Convert
  lvol0 vg   -wi----- 4.00m
  lvol1 vg   -wi-a--- 4.00m
  lvol2 vg   -wi----- 4.00m
  lvol3 vg   -wi----- 4.00m

(only vg/lvol1 activated as it passes the list and no other - correct!)
systemd: depend on systemd-udev-settle unit in activation unit

The "fedora-wait-storage.service" that the "lvm2-activation.service"
had as a dependency (which was fedora-specific solution anyway)
is obsolete now as this unit called "modprobe scsi_wait_scan"
which is not used anymore.

The "fedora-wait-storage.service" had "systemd-udev-settle" as
its dependency, so let's depend on this one directly now,
bypassing the out-dated "fedora-wait-storage.service".
TEST:  Add missing test for RAID module version

RAID10 was added to dm-raid module version 1.3.0.  Omitted test for
this version is causing test suite to fail.
RAID1:  Like mirrors, do not allow adding images to LV created w/ --nosync

Mirrors do not allow upconverting if the LV has been created with --nosync.
We will enforce the same rule for RAID1.  It isn't hugely critical, since
the portions that have been written will be copied over to the new device
identically from either of the existing images.  However, the unwritten
sections may be different, causing the added image to be a hybrid of the
existing images.

Also, we are disallowing the addition of new images to a RAID1 LV that has
not completed the initial sync.  This may be different from mirroring, but
that is due to the fact that the 'mirror' segment type "stacks" when adding
a new image and RAID1 does not.  RAID1 will rebuild a newly added image
"inline" from the existant images, so they should be in-sync.
RAID1:  Clear the LV_NOTSYNCED flag when a RAID1 LV is converted to linear

Failing to clear the LV_NOTSYNCED flag when converting a RAID1 LV to
linear can result in the flag being present after an upconvert - even
if the sync is performed when upconverting.
discards: skip when removing LVs on missing PVs

Don't try to issue discards to a missing PV to avoid segfault.
Prevent lvremove from removing LVs that have any part missing.

https://bugzilla.redhat.com/857554
lvs: add partial attribute
mirror:  'lvconvert --resync' should reset LV_NOTSYNCED on corelog mirror

When reformatting the 'lvchange_resync' code in commit
05131f5853e86419d9c726faa961b8d012298d9c, a '!' should have been removed
from the condition that checks for the LV_NOTSYNCED flag on a corelog
mirror LV.  The presence of this '!' caused the LV_NOTSYNCED flag to be
cleared when it wasn't present and left when it was present.

It is not allowed to add images to a 'mirror' or 'raid1' LV if the
LV_NOTSYNCED flag is set.  We add some up-convert tests to ensure this
behavior is being enforced and that the LV_NOTSYNCED flag is being
properly cleared by 'lvchange --resync'.

(Not updating WHATS_NEW because this is intrarelease.)
Fix tests to accept extended attribute

attr field had a character (p)artial appended.
cleanup: remove unused variable
TEST: Kill lvmetad early in teardown.
filters: Alwayz zalloc the filter struct.

Not all pointers need to be initialised explicitly that way.
dev-cache: Make it possible to pass in a NULL filter.
libdaemon: Extend and refactor APIs.

- move common dm_config_tree manipulation functions from lvmetad-core to
  daemon-shared
- add config-tree-based request manipulation APIs to daemon-client
- factor out _v (va_list) variants of most variadic functions in libdaemon
lib/cache/lvmetad: Refactor to use dm_config_tree in requests.

We were using daemon_send_simple until now, but it is no longer adequate, since
we need to manipulate requests in a generic way (adding a validity token to each
request), and the tree-based request interface is much more suitable for this.
example.conf.in: The command to refresh lvmetad is pvscan --cache.