Record the initial state of the Physical Web at startup

ios/chrome/browser/application_context_impl.cc

Index: ios/chrome/browser/application_context_impl.cc
diff --git a/ios/chrome/browser/application_context_impl.cc b/ios/chrome/browser/application_context_impl.cc
index 88bc2271dcae72be0e9009cab33d7bc8eec0c397..43e8945889aa616db235cd3f6bd2b13acf77cd76 100644
--- a/ios/chrome/browser/application_context_impl.cc
+++ b/ios/chrome/browser/application_context_impl.cc
@@ -289,7 +289,8 @@ physical_web::PhysicalWebDataSource*
 ApplicationContextImpl::GetPhysicalWebDataSource() {

[rohitrao (ping after 24h), 2016/12/12 12:54:17]

When is this method called for the first time?  Creating the data source
automatically starts the metrics collection, and the bluetooth callback is
scheduled on the main thread.  Is this something that we could delay for N
seconds after startup, so we're not running non-essential code in the critical
path of startup?

[mattreynolds, 2016/12/12 21:48:46]

It's first called during [MainController startUpBrowserForegroundInitialization]
when the browser view is switched.

I added a 10 second delay so we won't record the state until after
initialization is complete. The delay could affect the recorded state (eg, user
could grant the Location app permission before the delay expires) but it's
unlikely to be significant.

The preference state likely WILL change during the delay period since we have
logic to auto-enable the pref when certain conditions are met. We intentionally
capture the pref state before the delay to avoid grabbing it after the
auto-enable logic has executed.

   DCHECK(thread_checker_.CalledOnValidThread());
   if (!physical_web_data_source_) {
-    physical_web_data_source_ = CreateIOSChromePhysicalWebDataSource();
+    physical_web_data_source_ =
+        CreateIOSChromePhysicalWebDataSource(GetLocalState());
     DCHECK(physical_web_data_source_);
   }
   return physical_web_data_source_.get();