Move MediaDeviceIDSalt from ProfileIOData to ProfileImpl.

chrome/browser/profiles/profile_impl.h

Index: chrome/browser/profiles/profile_impl.h
diff --git a/chrome/browser/profiles/profile_impl.h b/chrome/browser/profiles/profile_impl.h
index 7956e02e5246a6b9660071a8cb14e548e0ced412..9cef255587b071cec7db2049a5e8bcfcbbd7fbe2 100644
--- a/chrome/browser/profiles/profile_impl.h
+++ b/chrome/browser/profiles/profile_impl.h
@@ -25,6 +25,7 @@
 #include "content/public/browser/host_zoom_map.h"
 #include "extensions/features/features.h"
 
+class MediaDeviceIDSalt;
 class PrefService;
 
 #if defined(OS_CHROMEOS)
@@ -97,6 +98,7 @@ class ProfileImpl : public Profile {
       const base::FilePath& partition_path,
       bool in_memory) override;
   void RegisterInProcessServices(StaticServiceMap* services) override;
+  std::string GetMediaDeviceIDSalt() override;
 
   // Profile implementation:
   scoped_refptr<base::SequencedTaskRunner> GetIOTaskRunner() override;
@@ -251,6 +253,8 @@ class ProfileImpl : public Profile {
 
   std::unique_ptr<PrefProxyConfigTracker> pref_proxy_config_tracker_;
 
+  scoped_refptr<MediaDeviceIDSalt> media_device_id_salt_;
+
   // STOP!!!! DO NOT ADD ANY MORE ITEMS HERE!!!!

[mmenke, 2017/04/18 18:52:16]

Note that I'm ignoring this, largely because this is already part of a content/
API, and I'm unaware of a good way to make this a service (Note that it has
consumers in chrome and content, a default behavior, and a special pref-based
behavior when run in Chrome).

I agree moving it makes sense, but I'm also reluctant to redesign a service I
neither own nor understand - I just want to remove the code from ProfileIOData,
as it's an even worse spot than here.  If someone on the media team that owns
the MediaDeviceIDSalt wants to do a more principled approach, I'm happy to hand
it off or work together on a better design.

[Mike Lerman, 2017/04/18 19:09:46]

webrtc_audio_private_api.cc is the only place in Chrome that needs to care about
the MediaDeviceIDSalt object or preference. Can we have that class either hold
the reference to the object (in place of the Profile) or just interact with, and
manage, the pref directly?

It seems like the answer here is that, since there's only one place in
chrome/browser that needs to care, to push the responsibility out of Profile
into there. It seems like, logically, the results would be equivalent; and while
we're going to the effort to move this logic out of profile_io_data, let's move
it out of chrome/browser/profiles completely.

[mmenke, 2017/04/18 20:04:57]

Are you sure?  Looks like
content/browser/renderer_host/render_process_host_impl.cc passes it to the
AudioRendererHost and MediaStreamDispatcherHost

   //
   // Instead, make your Service/Manager/whatever object you're hanging off the