Associate a scan mode with Physical Web listeners

components/physical_web/data_source/physical_web_data_source.h

Index: components/physical_web/data_source/physical_web_data_source.h
diff --git a/components/physical_web/data_source/physical_web_data_source.h b/components/physical_web/data_source/physical_web_data_source.h
index 1d03230e048ccc061f4dbccc14436f8232f91c74..eee858a680f02f347e743f6a6b6d20c07d091c35 100644
--- a/components/physical_web/data_source/physical_web_data_source.h
+++ b/components/physical_web/data_source/physical_web_data_source.h
@@ -16,6 +16,16 @@ namespace physical_web {
 
 class PhysicalWebListener;
 
+// Enum describing scan policies.
+enum ScanMode {
+  // Request no particular scan policy.  Opportunistic listeners will receive
+  // notifications when any other listener requests a scan.
+  OPPORTUNISTIC = 0,
+  // Request a scan that runs occassionally, even when Chrome is not in the
+  // foreground.  Android only.
+  BACKGROUND_INTERMITTENT = 1 << 0,

[mattreynolds, 2017/03/21 19:02:56]

What should we do if a client specifies an invalid scan mode? (eg,
BACKGROUND_INTERMITTENT on iOS). I think it would be reasonable to fall back to
OPPORTUNISTIC, but it might be better to emit an unsupported mode error.

[cco3, 2017/03/21 19:28:45]

I don't think a fall-back is necessary.  These are just policies that may be
requested, like hints.  If we get one we don't want to acknowledge, we just
ignore it.

+};
+
 // Metadata struct for associating data with Physical Web URLs.
 struct Metadata {
   Metadata();
@@ -89,7 +99,8 @@ class PhysicalWebDataSource {
   virtual bool HasUnresolvedDiscoveries() = 0;
 
   // Register for changes to Physical Web URLs and associated page metadata.
-  virtual void RegisterListener(PhysicalWebListener* physical_web_listener) = 0;
+  virtual void RegisterListener(PhysicalWebListener* physical_web_listener,
+      ScanMode scan_mode) = 0;
 
   // Unregister for changes to Physical Web URLs and associated page metadata.
   virtual void UnregisterListener(