Remove dependency on BrowserThread::FILE from Sync code

chrome/browser/extensions/api/storage/backend_task_runner.h

+// Copyright 2017 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+#ifndef CHROME_BROWSER_EXTENSIONS_API_STORAGE_BACKEND_TASK_RUNNER_H_
+#define CHROME_BROWSER_EXTENSIONS_API_STORAGE_BACKEND_TASK_RUNNER_H_
+
+#include "base/memory/ref_counted.h"
+#include "base/sequenced_task_runner.h"
+
+namespace extensions {
+
+// Gets the singleton task runner for running SyncStorageBackend on.
+scoped_refptr<base::SequencedTaskRunner> GetBackendTaskRunner();

[Devlin, 2017/06/21 19:19:31]

Since this is currently only used for SyncStorageBackend tasks, it might make
sense to instead put this as a static method in the SyncStorageBackend class,
e.g.

class SyncStorageBackend {
 public:
  static scoped_refptr<base::SequencedTaskRunner> GetTaskRunner();
}

[stanisc, 2017/06/22 22:34:16]

SyncStorageBackend seems like a wrong place. I think this task runner would have
to trickle all the way to LeveldbValueStore because it currently does a bunch of
DCHECK_CURRENTLY_ON(BrowserThread::FILE) checks. There might be multiple
solutions:
1) Put the task runner in a class that would logically apply to the lower levels
of implementation of the storage like LeveldbValueStore but still make it
reasonable to be
accessed from the sync code.
2) Pass the task runner into LeveldbValueStore so that it can validate that it
is 
running on the right task runner sequence.
3) Remove these BrowserThread::FILE checks from LeveldbValueStore and replace
them 
with something more generic like AssertIOAllowed.

If we pick #2 or #3 than it should be OK to define the task runner at
SyncStorageBackend level. That should also allow to have different task runners
for different storages in the extensions subsystem rather than serialize
everything on the same task runner.
Would you prefer this approach or one singleton task runner used for everything
within extensions?
prefer this 

[stanisc, 2017/06/23 21:00:23]

I'll leave it this way and re-evaluate in the next patch when I convert
SyncStorageBackend and other related extensions classes.

[Devlin, 2017/06/23 21:23:35]

I think #3 (preferring AssertIOAllowed) is probably the most appropriate (but no
need to do that in this CL).

+
+}  // namespace extensions
+
+#endif  // CHROME_BROWSER_EXTENSIONS_API_STORAGE_BACKEND_TASK_RUNNER_H_