device: make sure to always retroactively start device dependencies

device: make sure to always retroactively start device dependencies

PID1 updates the state of device units upon 2 different events:

 - when it processes an event sent by udev and in this case the device deps are
   started if the device enters in the "plugged" state.

 - when it enumerates all devices during its startup or when it is asked to
   reload its configuration data but in this case the device deps (if any) are
   not retroactively started.

When udev processes a new "add" kernel event, it first registers the new device
in its databases then sends an event to systemd.

If for any reason, systemd is asked to reload its configuration between the
previous 2 steps, it might see for the first time the new device while scanning
/sys for all devices. Only during a second step, udev will send the event for
the new device.

In this peculiar case the device deps wont be started (even though the device
is first seen by PID1).

Indeed when reloading its configurations, PID1 will put the device unit in the
"plugged" state but without starting the device deps. Thereafter PID1 will get
the event from udev for the new device but the device unit will be in "plugged"
state already therefore it won't see any need to start the device dependencies.

Rather than assuming that during the reloading of systemd manager configuration
all devices listed in udev DBs have been already processed and should be put in
the "plugged" state (done by device_coldplug()), this patch does that only for
devices which have been processed via an udev event (device_dispatch_io())
previously. In this case we set "d->found" to "DEVICE_FOUND_UDEV" and we make
also sure to no more initialize "d->found" while enumerating devices. Instead
this field is now saved/restored while devices are serialized.