dmsetup: add warning

Warn when --udevcookie/DM_UDEV_COOKIE is used with 'dmsetup remove --force'.

When command is doing multiple ioctl operations on a single device,
it may invoke udev activity, that is colliding with further ioctl commands.
The result of such operation becomes unpredictable.
Use of --retry could partially help...
man: cleanup dmsetup

Add few bold texts.
cleanup: internal error for impossible path

Add 'default' path for impossible execution code path.
tests: update aux disable_dev

disable_dev can't use transaction - since it may lead occasionaly to
weird error - example could be nomda-missing.sh test case.
Here occasionaly device instead of being removed was left as
error device and testing different code path (which is unfortunatelly
buggy)

When we want to test 'error' device -  'aux error_dev()' should be used.
tests: support thin_restore configurable

Currently this tool is used only in tests.
udev: also print subsystem udev flags in debug message about udev flags + fix typo DM_SUBSSYTEM_UDEV_FLAG7 -> DM_SUBSYSTEM_UDEV_FLAG7
activate: cleanup lv_check_not_in_use

Reindent lv_check_not_in_use to simplify internal loop code.
Also return always '0/1'  (drop -1) - since we only
check for failure (0) - and we don't really know
why  lv_info() has failed.
raid: cleanup error messages

Add log_error messages on error paths.
tests: detect same uuid on PV

Check we know how to handle same UUID
Test  currently does NOT work on lvmetad
(or it's unclear it even should - thus test error
is currently lowered to 'test warning')

TODO: replace lib/test with a better shell script name
tests: raid syncaction activation race

Demonstrace problem of syncaction being called right after activation.
tests: dd needs to hit disk

Unsure if this is feature or bug of syncaction,
but it needs to be present physically on the media
and it ignores content of buffer cache...

(maybe lvchange should implicitely fsync all disks
that are members of raid array before starting test??)
revert: restore original timeout

Accidently it's been commited - but it has also shown,
that on heavy loaded systems (like our test machine could be)
slightly bigger timeouts which waits longer for udev rules
processing does help and avoids occasional refuse of deactivation
because device is still being open.
(i.e. lvcreate...; lvchange -an...)

Unsure how we could now synchronize for this. On very slow(/loaded)
system 5 second timeout is simply not enough.

TODO: introduce at least lvm.conf configurable setting to
allow longer 'retry' loops.
tests: rename test
activation:  Remove empty DM device when table fails to load.

As part of better error handling, remove DM devices that have been
sucessfully created but failed to load a table.  This can happen
when pvmove'ing in a cluster and the cluster mirror daemon is not
running on a remote node - the mapping table failing to load as a
result.  In this case, any revert would work on other nodes running
cmirrord because the DM devices on those nodes did succeed in loading.
However, because no table was able to load on the non-cmirrord nodes,
there is no table present that points to what needs to be reverted.
This causes the empty DM device to remain on the system without being
present in any LVM representation.

This patch should only be considered a partial fix to the overall
problem.  This is because only the device which failed to load a
table is removed.  Any LVs that may have been loaded as requirements
to the DM device that failed to load may be left in place.  Complete
clean-up will require tracking those devices which have been created
as dependencies and removing them along with the device that failed
to load a table.
report: fix report field type for lv_kernel_major/minor

Should be defined as numeric field, not string field.
test: use direct I/O when injecting bad data into RAID images

When directly corrupting RAID images for the purpose of testing,
we must use direct I/O (or a 'sync' after the 'dd') to ensure that
the writes are not caught in the buffer cache in a way that is not
reachable by the top-level RAID device.