Use ScopedTaskEnvironment instead of MessageLoop in /content/browser/screenlock_monitor

MessageLoop will go away, eventually.

ScopedTaskEnvironment will per default start a ThreadPool, which should
be fine in most of the cases. If you belive your test needs to make sure
that no ThreadPool runs let me know and I will update the patch.

BUG=891670
This CL was uploaded by git cl split.

R=braveyao@chromium.org

Change-Id: I574c959c6ab245e188386d0cbad5d8b3c2b4c789
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1649512
Auto-Submit: Carlos Caballero <carlscab@google.com>
Reviewed-by: Weiyong Yao <braveyao@chromium.org>
Commit-Queue: Weiyong Yao <braveyao@chromium.org>
Cr-Commit-Position: refs/heads/master@{#667189}

content/browser/screenlock_monitor/screenlock_monitor_unittest.cc

@@ -5,9 +5,9 @@
 #include "content/browser/screenlock_monitor/screenlock_monitor.h"
 
 #include "base/macros.h"
-#include "base/message_loop/message_loop.h"
 #include "base/message_loop/message_loop_current.h"
 #include "base/run_loop.h"
+#include "base/test/scoped_task_environment.h"
 #include "content/browser/screenlock_monitor/screenlock_monitor_source.h"
 #include "testing/gtest/include/gtest/gtest.h"
 
@@ -61,7 +61,7 @@ class ScreenlockMonitorTest : public testing::Test {
   std::unique_ptr<ScreenlockMonitor> screenlock_monitor_;
 
  private:
-  base::MessageLoop message_loop_;
+  base::test::ScopedTaskEnvironment scoped_task_environment_;
 
   DISALLOW_COPY_AND_ASSIGN(ScreenlockMonitorTest);
 };