Add TaskPriority as a parameter to SequencedWorkerPool in preparation for TaskScheduler experiment.

device/bluetooth/bluetooth_task_manager_win.cc

Index: device/bluetooth/bluetooth_task_manager_win.cc
diff --git a/device/bluetooth/bluetooth_task_manager_win.cc b/device/bluetooth/bluetooth_task_manager_win.cc
index fdef7d85fda67599cc7b9c35e5b54c8209b93555..ea2a630e8a97a2e6beba506c070a05f4f29b79f9 100644
--- a/device/bluetooth/bluetooth_task_manager_win.cc
+++ b/device/bluetooth/bluetooth_task_manager_win.cc
@@ -257,8 +257,9 @@ void BluetoothTaskManagerWin::RemoveObserver(Observer* observer) {
 
 void BluetoothTaskManagerWin::Initialize() {
   DCHECK(ui_task_runner_->RunsTasksOnCurrentThread());
-  worker_pool_ = new base::SequencedWorkerPool(kNumThreadsInWorkerPool,
-                                               kBluetoothThreadName);
+  worker_pool_ = new base::SequencedWorkerPool(
+      kNumThreadsInWorkerPool, kBluetoothThreadName,
+      base::TaskPriority::USER_BLOCKING);

[scheib, 2016/06/23 00:49:30]

I'm not fully familiar with the priority levels, but this may be unnecessarily
high. Some of the bluetooth actions are visible in user interface, e.g. when
discovering devices. And, reading and writing values may happen as a part of
user interface interaction (including via web page UI). But, I do not believe
any of these APIs presume a very rapid response, e.g. expected to appear as
'instant' when reacting to a user button press instantly, or animation, etc.

Perhaps USER_VISIBLE is reasonable.

I don't expect this code to be exercised very much currently. 

[gab, 2016/06/27 21:29:32]

SGTM, thanks, done.

   InitializeWithBluetoothTaskRunner(
       worker_pool_->GetSequencedTaskRunnerWithShutdownBehavior(
           worker_pool_->GetSequenceToken(),