sensors: Clean up sequence, task and thread handling in the Linux implementation

Bug 941559 refers to a DCHECK hit in
device::PlatformSensorProviderLinux::StopPollingThread() caused by the fact
that polling thread we create was being stopped in a task that shouldn't
block.

Use this as an excuse to do some long-needed cleanup in the Linux code by
making it follow a more recommended style when interacting with the task
scheduler API.

The essence of the change is that we do not need a polling thread (which is
a bare base::Thread) in the first place. Not only that, but we do not need
to create it in PlatformSensorProviderLinux and pass it around to
PlatformSensorLinux (which then used this thread's task runner to call
specific parts of SensorReader).

Instead, we move the responsibility of setting up the infrastructure to do
blocking I/O to the place that actually needs it: PollingSensorReader. This
way, we can just create a blocking SequencedTaskRunner there and use it to
drive a newly-created BlockingTaskHelper class that performs the
base::ReadFile calls while PollingSensorReaderLinux acts as a wrapper around
it running in a regular sequence. This change is inspired by //device/usb's
UsbServiceLinux which does something similar.

While here, use a SequenceChecker rather than a ThreadChecker for
PollingSensorReader, as we do not need thread-affinity here to begin with.

TEST=service_unittests --gtest_filter=PlatformSensorAndProviderLinuxTest.\*,
     visiting multiple pages that create sensors with Chrome and then
     closing it, both in debug mode

Bug: 941559
Change-Id: Ia93a166476383e0f559c693f1c70434b77a8f504
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1526047
Commit-Queue: Raphael Kubo da Costa <raphael.kubo.da.costa@intel.com>
Reviewed-by: Reilly Grant <reillyg@chromium.org>
Auto-Submit: Raphael Kubo da Costa <raphael.kubo.da.costa@intel.com>
Cr-Commit-Position: refs/heads/master@{#641362}
5 files changed