Add a test to cover service worker update codepath when extension is updated

extensions/browser/service_worker_manager.cc

Index: extensions/browser/service_worker_manager.cc
diff --git a/extensions/browser/service_worker_manager.cc b/extensions/browser/service_worker_manager.cc
index 16167d4e3d9cfa31b25e5602c9fbb32d4b68f1b3..2198eb8355fb89a288e53a3b5b524f87468058eb 100644
--- a/extensions/browser/service_worker_manager.cc
+++ b/extensions/browser/service_worker_manager.cc
@@ -48,4 +48,20 @@ void ServiceWorkerManager::OnExtensionUninstalled(
       ->DeleteForOrigin(extension->url(), base::Bind(&EmptySuccessCallback));
 }
 
+void ServiceWorkerManager::OnExtensionWillBeInstalled(
+    content::BrowserContext* browser_context,
+    const Extension* extension,
+    bool is_update,
+    bool from_ephemeral,
+    const std::string& old_name) {
+  if (is_update) {
+    // TODO(lazyboy): This is racy because this relies on DeleteForOrigin() to

[lazyboy, 2015/11/10 00:45:44]

How can we fix this?
Or, is there any guarantee that would make the deletion code run before the
browser sees the next SW registration? (== no race)

I'm still learning the threading here, how many threads would involve this call
below? SW thread + File thread to store/retrieve the worker?

[Devlin, 2015/11/10 16:59:50]

Hmm... I would hope that it wouldn't be racy, because any registration would
also have to do the same thread-hopping, and we ensure that posted tasks are
FIFO.  Or does registration/access somehow bypass the thread-hop?

And I think most of these SW calls execute on the IO thread, so we should only
be involving the UI thread (here) and the IO thread (for the SW update), IIUC.

+    // finish before updated extension (re)registers the service worker.
+    content::BrowserContext::GetStoragePartitionForSite(browser_context_,
+                                                        extension->url())
+        ->GetServiceWorkerContext()
+        ->DeleteForOrigin(extension->url(), base::Bind(&EmptySuccessCallback));

[Devlin, 2015/11/10 16:59:50]

(Sorry if this was just a placeholder and I'm saying something you already
know.)
We don't actually want to delete the SW for the orgin, because we don't want to
invalidate any cached data or lose the registration.  We just want to make sure
we re-fetch the service worker (similar to what we do after 24 hours on a normal
web page).

[lazyboy, 2015/11/11 00:56:27]

I've changed this to eventually call
ServiceWorkerRegistration::set_force_update_on_page_load().
That seems to PASS the tests.

Let me know if this sounds about right, then I'll pass the
CL to an SW OWNER.

+  }
+}
+
 }  // namespace extensions