Occasionally no recontextualization on CD-ROM change

[vholer]

On KVM, one of the events to trigger recontextualization in VM is the change of the context CD-ROM.

On Debian/Ubuntu/RH, the udev generates 2 nearly same events about the CD-ROM change. In configuration of context packages, we do have a silly filtering by event sequential number to catch only a one of those events (as there is nothing else how to distinguish them):

addon-context-linux/src/lib/udev/rules.d/65-context.rules##deb.one

Lines 15 to 21 in bfba520

	# When CONTEXT CD-ROM is changed, it generates 2 events. This rule takes
	# every second event and triggers systemd service one-context-reconfigure.
	# This service also stops any existing delayed reconfiguration.
	SUBSYSTEM=="block", ACTION=="change", \
	ENV{ID_CDROM}=="1", \
	ENV{ID_FS_TYPE}=="iso9660" ENV{ID_FS_LABEL_ENC}=="CONTEXT", \
	ENV{SEQNUM}=="*[02468]", \

which relies on the fact that the events have contiguous sequential numbers, where one will be even and one odd.

After a stress testing we found a rare cases when such events don't have contiguous sequential numbers. They don't match the udev configuration and don't trigger recontextualizatoin. In following example we see both sequential numbers are odd (X, X+2):

$ udevadm monitor -u -s block/disk -p | egrep "^SEQNUM|UDEV"
...
UDEV  [22.194918] change   /devices/pci0000:00/0000:00:01.1/ata1/host0/target0:0:0/0:0:0:0/block/sr0 (block)
SEQNUM=5551
UDEV  [22.261865] change   /devices/pci0000:00/0000:00:01.1/ata1/host0/target0:0:0/0:0:0:0/block/sr0 (block)
SEQNUM=5553

It should be evaluated how current systems behave if we drop the filtering.

[vholer]

Dropped events filtering udev (affected rpm/deb systems).

On systemd platforms, we trigger reconfiguration service with --no-block and the second event doesn't trigger another run, as the service is already running. On minority of non-systemd Debian platforms (Devuan), two reconfiguration services are started, but the second one doesn't detect any changes and terminates.