This FR is inspired by this CL:
    https://chromium-review.googlesource.com/#/c/331061/
However, the problem it poses is more general.

Currently, udev triggering happens in two upstart jobs
in common boot code:
  * udev-trigger-early triggers for some specified devices, and
    blocks boot-services.
  * udev-trigger starts after Chrome, and triggers devices
    not handled by udev-trigger-early.

From time to time, we've seen the need for board/platform
specific triggers.  Constantly adding device classes to
udev-trigger-early is slightly unwieldy and isn't always
appropriate.  We need a more flexible design.

With that thought, I think the following would work:

Add a "device-services" upstart job that looks like this:
    start on started udev

    pre-start exec udevadm settle

Make these changes to "udev-trigger-early":
  * Change to use "start on starting device-services".
  * Make the job a task.
  * Drop the invocation of `udevadm settle`.

Change the start condition for "boot-services" to be
    start on stopped startup and started device-services and stopped boot-splash

After these changes, any platform needing device specific
udev triggers can write a job along these lines:
    start on starting device-services
    task

    script
      "udev trigger or other commands, as needed"
    end script

The job doesn't need "udevadm settle", and shouldn't use it.

This scheme has the following properties:
  * Device detection that's deemed critical to Chrome can
    force Chrome to wait until the devices are ready.
  * Device detection can start without waiting for
    chromeos_startup or the splash screen, allowing
    more potential for parallelism in startup.