Run RemoveArcData after a user has opted out

chrome/browser/chromeos/chrome_browser_main_chromeos.h

Index: chrome/browser/chromeos/chrome_browser_main_chromeos.h
diff --git a/chrome/browser/chromeos/chrome_browser_main_chromeos.h b/chrome/browser/chromeos/chrome_browser_main_chromeos.h
index eb33f493433b56dc84195f846a2b3902441676b2..c093027044c80d7f3a65255abfe1984c35ebc599 100644
--- a/chrome/browser/chromeos/chrome_browser_main_chromeos.h
+++ b/chrome/browser/chromeos/chrome_browser_main_chromeos.h
@@ -18,6 +18,7 @@ class SessionManager;
 }
 
 namespace arc {
+class ArcDataManager;
 class ArcServiceLauncher;
 }
 
@@ -84,6 +85,7 @@ class ChromeBrowserMainPartsChromeos : public ChromeBrowserMainPartsLinux {
   scoped_refptr<chromeos::ExternalMetrics> external_metrics_;
 
   std::unique_ptr<arc::ArcServiceLauncher> arc_service_launcher_;
+  std::unique_ptr<arc::ArcDataManager> arc_data_manager_;

[stevenjb, 2016/05/13 17:13:55]

We should make this part of arc_service_launcher_ so that we only have the one
awkward singleton to manage. We may want to rename ArcServiceLauncher at that
point, but the more awkward singletons we have to manage the more likely we will
introduce edge cases and shutdown crashes.

(I would also suggest changing ArcServiceLauncher so that Initialize and
Shutdown were static methods that create and destroy the global singleton
instead of this implicit singleton model, but that can be discussed separately).

[dspaid, 2016/05/15 23:58:51]

I'm not sure I understand how this would work.  Right now there's way to get a
pointer to ArcServiceLauncher from where this is used in UserSessionManager. 
Adding a static Get to ArcServiceLauncher just moves the problem from one class
to another... If there's some guarantee that UserSessionManager will be
initialized by the time ArcServiceLauncher is created I could add a
SetArcServiceLauncher method, but similar would have to be done for every future
use of these classes as well.

[stevenjb, 2016/05/16 15:56:06]

The current model that Arc is using, from a somewhat quick glance, is:
ArcServiceLauncher owns ArcServiceManager.
ArcServiceManager owns a vector of services.
Each service has a static getter, e.g. arc::ArcAuthService::Get().

I am proposing that we keep ownership of all arc related global instances in
ArcServiceManager, including ArcUserDataManager. ArcUserDataManager whould still
have a static Get() method, and we would still have potential issues with
construction / destruction order, but at least we are not proliferating the
number of arc globals owned elsewhere (i.e. here).

Then, ideally, at some point we can pass ArcServiceLauncher (or something
similar) to UserSessionManager (and other classes that use it) and get rid of
the global accessors.

 
   DISALLOW_COPY_AND_ASSIGN(ChromeBrowserMainPartsChromeos);
 };