Tiny: Post PerformFullHashCheck on IO thread, instead of calling it synchronously.

components/safe_browsing_db/v4_local_database_manager.cc

Index: components/safe_browsing_db/v4_local_database_manager.cc
diff --git a/components/safe_browsing_db/v4_local_database_manager.cc b/components/safe_browsing_db/v4_local_database_manager.cc
index e489946da80f5a59bf471d97b3392b0571b4b531..34d09f21a4f671ddd4dc76629d78ada793c5b2d9 100644
--- a/components/safe_browsing_db/v4_local_database_manager.cc
+++ b/components/safe_browsing_db/v4_local_database_manager.cc
@@ -147,7 +147,11 @@ bool V4LocalDatabaseManager::CheckBrowseUrl(const GURL& url, Client* client) {
     return true;
   }
 
-  PerformFullHashCheck(std::move(check), full_hash_to_store_and_hash_prefixes);
+  BrowserThread::PostTask(
+      BrowserThread::IO, FROM_HERE,
+      base::Bind(&V4LocalDatabaseManager::PerformFullHashCheck, this,
+                 base::Passed(std::move(check)),
+                 full_hash_to_store_and_hash_prefixes));

[Scott Hess - ex-Googler, 2016/10/14 00:40:59]

I was thinking this might introduce an extra spin of the loop versus v3, but ...
v3 transitions through the UI thread on fetch?  To get the extended-reporting
flag.  OMG.

Anyhow, where I was going with that is that I think right now this would post a
task, and that task might startup a fetcher which would post another task, so
worst-case you'll have two additional tasks to process.  Best case you'll have
one.  I think right now you have enough info to reduce that to one in either
case (either post the task leading directly to RespondToClient, or start the
fetcher leading to RespondToClient later).

[I am open to the argument "That's too complicated" or "It can be a TODO" or
"The fetcher can callback synchronously, and it's hard to detect."]

[[I'm not fresh enough to reason about interactions with StopOnIOThread().]]

   return false;
 }