In a container with a non-trivial user namespace, we cannot rely on
libudev communicating with udevd as a way to monitor device nodes,
for the following reasons:

* If uid 0 from the host is not mapped to uid 0 in the container, libudev
  cannot authenticate netlink messages from the host, because their sender
  uid appears to be the overflowuid. Resolving this by mapping uid 0 into
  the container is not allowed when creating user namespaces as an
  unprivileged user, and even when running as a privileged user, it might
  be desirable for the real uid 0 to not be mapped as a way to harden the
  security boundary between container and host.

* Depending on the container configuration, initial enumeration might
  not be able to read /run/udev from the host system. If it can't, sysfs
  attributes will still work because those are read directly from the
  kernel via sysfs, but udev properties coming from user-space rules
  (in particular ID_INPUT_JOYSTICK and friends) will appear to be missing.

* The protocols between udevd and libudev (netlink messages for monitoring,
  and /run/udev for initial enumeration) are considered to be private to
  a particular version of udev, and are not a stable API; but in a
  container, we cannot expect that our copy of libudev is at exactly the
  same version as udevd on the host system.

Sidestep this by adding a code path that continues to use libudev for
the parts that work regardless of whether udevd is running or can be
communicated with.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>