fix: Start after systemd-udev

[ReillyBrogan]

Having After=multi-user.target as well as WantedBy=multi-user.target isn't really a useful combination for a service since that means that systemd will wait for the rest of multi-user.target to be loaded before starting lactd.service and only once it finishes starting lactd.service will it continue with starting things that depend on multi-user.target. Doing that will increase time-to-login-manager by however long it takes lactd.service to start since the otherwise-parallel service startup will be blocked until that completes. Instead we can have it start after systemd-udev by which point the kernel modules should already be loaded.

[ilya-zlobintsev]

I'm not sure about this change - from past testing (granted, this was a few years ago) waiting systemd-udev was not enough to have a properly initialized SysFS hierarchy for AMD GPUs. In fact, even the current multi-user.target dependency was not enough on some systems, which is why additional logic in the application was added to wait for the devices to come up.

These days early init of the service should not be an issue, as it listens to DRM kernel events in order to pick up any other devices that may have been loaded since the service was started, but I still wouldn't want to entirely rely just on that.

Doing that will increase time-to-login-manager by however long it takes lactd.service to start

Considering there is no readiness/health check in the service, is this a problem? SystemD should consider the service as starting instantly.