initscripts: add pidfile reference in chkconfig header for clvmd and cmirrord

When the init scripts are run from within systemd, the systemd
needs to know the pidfile for it to work correctly when the
daemon itself is killed. Otherwise, systemd keeps these services
in "active" and "exited state" at the same time
(it assumes RemainAfterExit=yes without the pidfile reference in
chkconfig header).

See also https://bugzilla.redhat.com/show_bug.cgi?id=971819#c5.
test: Avoid hardcoding path to bash (not all systems have /bin/bash).
Move export_vg_to_config_tree alongside export_vg_to_buffer.
Add and track an "ondisk" pointer to struct volume_group.

This allows us to get the current on-disk version of the metadata whenever we
have the current in-flight version, without a recourse to scanning or lvmcache.
locking: Make it possible to pass down an LV to activation code.

Previously, we have relied on UUIDs alone, and on lvmcache to make getting a
"new copy" of VG metadata fast. If the code which triggers the activation has
the correct VG metadata at hand (the version which is currently on disk), it can
now hand it to the activation code directly.
Actually pass LV metadata to activation code, when available.

This ties the two preceding changes together, actually using the "ondisk"
version of VG metadata instead of calling into lvmcache when activating
volumes. The cache hooks are still used as a fallback, because we don't have an
uncached scanning API yet.
metadata: Fix a pool CRC failure due to "late" ondisk copy creation.
activation: Pass both ondisk and incore LV to suspend.
format1: Fix snapshot reload in lv_remove.

The special suspend/resume code in lv_remove for LVM1 snapshots was interpsersed
with a vg_commit call. However, while with LVM1 metadata, vg_commit is
technically a no-op, the activation code relied on the ondisk and incore
metadata being the same, since on LVM1, a "commit" happens in vg_write
already. Since the "ondisk" metadata was previously not available with format1
(and incore was silently used instead, via lvmcache), the problem was masked.
cleanup: move lv assignment

Use shorter  lv->.
cleanup: remove {}
cleanup: skip test if already tested for SIGN_PLUS
snapshots: check for active state

Fix testing if the snapshot could be resized and use lv_is_active()
to get correct answer in cluster.
thin: report t for thin pool and volume

Do not mark internal device _tdata and _tmeta as having target type 't'.
They have the target type on their own (i.e. mirror, raid).
thin: report o as volume type for external origin

Reuse 'o' attr for lvs report also for external origin.
thin: report 'e' metadata type with higher priority

Giving volume type information about being 'metadata' type of volume
has higher priority then i.e.  'mirror' or 'thin' flag - for those
type we have 'target attr' (7th. field).
thin: detect online metadata resize support
thin: add helper functions

Add find_pool_lv() and pool_can_resize_metadata().
thin: lvresize supports pool metadata resize

Add support for lvresize of thin pool metadata device.

lvresize --poolmetadatasize +20   vgname/thinpool_lv

or

lvresize -L +20 vgname/thinpool_lv_tmeta

Where the second one allows all the args for resize (striping...)
and the first option resizes accoding to the last metadata lv segment.
thin: enable resize for thin pool metadata LV

Support 'clasic' way of resizing of metadata LV.
Normally we disallow to work with internal 'invisible' devices.
But in this case we can make an exception and if user has some
special needs how to extend thin pool metadata LV - support it.

After resize of metadata LV, the pool will be suspended and resumed,
to be notified of this change.