Have mash_browser_tests recreate BackgroundServiceManager per test

services/ui/service.cc

Index: services/ui/service.cc
diff --git a/services/ui/service.cc b/services/ui/service.cc
index 673110cd2f27522009655a1d21d6adaed28af637..7cdd31e1d05cc455ecc9bb6aed2ce817cc1c630a 100644
--- a/services/ui/service.cc
+++ b/services/ui/service.cc
@@ -111,7 +111,10 @@ void Service::InitializeResources(service_manager::Connector* connector) {
   catalog::ResourceLoader loader;
   filesystem::mojom::DirectoryPtr directory;
   connector->BindInterface(catalog::mojom::kServiceName, &directory);
-  CHECK(loader.OpenFiles(std::move(directory), resource_paths));
+  if (!loader.OpenFiles(std::move(directory), resource_paths)) {

[sky, 2017/05/12 17:16:47]

The reason this CHECKs is because to do otherwise leaves the client in a very
bad state, a state that they are likely to crash on soon. For example,
Resourcebundle is not registered if you early return so that any access to it is
going to CHECK. In other words, I think an early return here is just going to
push the crash around.

What client is being started after the filesystem shuts down?

[jonross, 2017/05/12 18:08:02]

There appears to be a race on short run tests which don't bring up visuals.

As the UI Service wouldn't be done initializing by the time the ServiceContext
for the filesystem has been destroyed.

So while UI service is completely useless without these resources, it would
subsequently be notified of teardown. And cleanly shutdown.

Would it be more appropriate to use this as an additional signal to start the
shutdown?

+    LOG(ERROR) << "Service failed to open resource files.\n";
+    return;
+  }
 
   ui::RegisterPathProvider();