mojo leveldb: Get profile and leveldb connected to DOMStorageContext.

Building on the last patch which built mojo:profile and built one
for each BrowserContext, we move the LevelDBService in the profile
application to a dedicated leveldb thread to avoid deadlocks.
(Since applications all run on one thread by default, leveldb would
deadlock while waiting for profile to return data.)

This patch connects to the correct applications in
DOMStorageContextWrapper and then vends a LevelDBService instance to
each LevelDBWrapperImpl, for future use.

BUG=586194
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_site_isolation

Review URL: https://codereview.chromium.org/1737933002

Cr-Commit-Position: refs/heads/master@{#382343}

1 files changed, 5 insertions, 2 deletions

diff --git a/components/filesystem/lock_table.h b/components/filesystem/lock_table.h
index 9be4ca6..73674ac2 100644
--- a/components/filesystem/lock_table.h
+++ b/components/filesystem/lock_table.h
@@ -8,6 +8,7 @@
 #include <set>
 
 #include "base/files/file.h"
+#include "base/memory/ref_counted.h"
 
 namespace filesystem {
 
@@ -16,10 +17,9 @@ class FileImpl;
 // A table of all locks held by this process. We have one global table owned by
 // the app, but accessible by everything just in case two connections from the
 // same origin try to lock the same file.
-class LockTable {
+class LockTable : public base::RefCounted<LockTable> {
  public:
   LockTable();
-  ~LockTable();
 
   // Locks a file.
   base::File::Error LockFile(FileImpl* file);
@@ -33,6 +33,9 @@ class LockTable {
   void RemoveFromLockTable(const base::FilePath& path);
 
  private:
+  friend class base::RefCounted<LockTable>;
+  ~LockTable();
+
   // Open, locked files. We keep track of this so we quickly error when we try
   // to double lock a file.
   std::set<base::FilePath> locked_files_;