- use installTargets again ("install", and
   "install_systemd_{generators,units,configuration}" when udev is not
   null)
 - The call to the blkid binary in lvm2's 13-dm-disk.rules file
   disappeared (so we don't need to patch in blkid anymore).
   lvm seems to rely on udev's internal blkid functionality.
 - Call /run/current-system/systemd/bin/udevadm instead
   of ${systemd}/bin/udevadm in the lvm activation generator.
   This is not necessary to break the dependency cycle (as we don't use
   that file when building without udev), but a good idea anyways -
   We want to trigger the udevadm of the current system, not the one
   that lvm was built with.

Otherwise, we end up in a dependency cycle:

systemd -> cryptsetup -> lvm -> fetchgit -> git -> openssh -> libfido2 -> hidapi -> libusb -> udev=systemd

This seems to be mostly used to simplify LV management tasks from a web
interface
(https://www.redhat.com/archives/linux-lvm/2008-September/msg00029.html),
and is as fat as the `lvm` binary itself

This shuts up some warnings.

Introduce a pkgs.lvm2_dmeventd that contains dmeventd support, and
enable if services.lvm.dmeventd.enable is true.

This is already handled by the lvm module, which now properly adds the
lvm systemd generators.

Initially introduced in c0fd887.

Also, add some sleep statements in between, which seems to at least feel
like it causes

> WARNING: Device /dev/vda* not initialized in udev database even after waiting 10000000 microseconds.

To occur less frequently.

This eventually still succeeds after some amount of waiting, I suspect
some racyness in the way lvm's udev-triggered scripts trigger other
units.

Make this more consistent with how these flags look like in the rest of
nixpkgs.

lvm: cleanups