Migrate components/data_reduction_proxy to Mojo interfaces.

components/data_reduction_proxy/content/browser/data_reduction_proxy_host_impl.h

+// Copyright 2015 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+#ifndef COMPONENTS_DATA_REDUCTION_PROXY_CONTENT_BROWSER_DATA_REDUCTION_PROXY_HOST_IMPL_H_
+#define COMPONENTS_DATA_REDUCTION_PROXY_CONTENT_BROWSER_DATA_REDUCTION_PROXY_HOST_IMPL_H_
+
+#include "base/macros.h"
+#include "components/data_reduction_proxy/content/common/data_reduction_proxy.mojom.h"
+#include "mojo/public/cpp/bindings/strong_binding.h"
+
+namespace net {
+class HostPortPair;
+}
+
+namespace data_reduction_proxy {
+
+class DataReductionProxyConfig;
+class DataReductionProxySettings;
+
+class DataReductionProxyHostImpl : public mojom::DataReductionProxyHost {
+ public:
+  static void Create(DataReductionProxySettings* settings,
+                     mojom::DataReductionProxyHostRequest request);
+
+  // |settings| may be null.
+  DataReductionProxyHostImpl(DataReductionProxySettings* settings,
+                             mojom::DataReductionProxyHostRequest request);
+  ~DataReductionProxyHostImpl() override;
+
+  // mojom::DataReductionProxyHost methods:
+  void IsDataReductionProxy(
+      const net::HostPortPair& proxy_server,
+      const IsDataReductionProxyCallback& callback) override;
+
+ private:
+  // Must outlive |this|. May be null.

[Anand Mistry (off Chromium), 2016/06/16 09:04:04]

How can you guarantee this? The legacy IPC achieved this because the message
filter is attached to the RenderProcessHost and will be destroyed when the RPH
is gone. I'm assuming the RPH outlives the Profile. However, this class's
lifecycle is disconnected from the RPH and instead governed by the life of the
message pipe.

[leonhsl(Using Gerrit), 2016/06/17 08:43:57]

Yeah it is, the lifecycle is the difference with before. Thanks a lot for
pointing out this. I investigated around and I think we may have 2 options now:
1, 
Just for current use case, client side(PageLoadHistograms::Dump() on renderer
thread) executes "Connect-->Sync call-->Disconnect" all at once, message pipe
lifetime is just this timeslot, and the same to  DataReductionProxyHostImpl,
while within this timeslot the browser side RPH should just be keeping
alive(because renderer thread is running one task). This means we're still
achieving "RPH outlives DataReductionProxyHostImpl", so should have no problem..
 Maybe I'm saying something stupid,, but just my understanding now ;-) 
2,
Let DataReductionProxyHostImpl be a RPH observer so that it can connect
lifecycle with RPH. Once got RPH destroyed notification, post a task to IO
thread to delete itself.
 
WDYT? Thanks. If option1 is nonsense, I'll try option2.

[Sam McNally, 2016/06/20 04:57:26]

The lifetime in the renderer doesn't directly correspond to lifetime in the
browser. IsDataReductionProxy() won't be called synchronously when the pipe is
bound and neither will the disconnect.

On the other hand, using a RenderProcessHostObserver would be messy at
destruction time if the StrongBinding still lives on the IO thread as the UI and
IO threads could both decide to delete this at the same time.

[leonhsl(Using Gerrit), 2016/06/20 10:51:51]

Option1, I think the renderer thread will block on calling
IsDataReductionProxy() until pipe bound and IsDataReductionProxy() execution
returned in browser side. Within this timeslot, browser side RPH should be alive
and DataReductionProxyConfig should be guaranteed available.

Option2, yes it would be messy and hard to solve the race. Let me think more..

+  DataReductionProxyConfig* config_;
+
+  mojo::StrongBinding<mojom::DataReductionProxyHost> binding_;
+
+  DISALLOW_COPY_AND_ASSIGN(DataReductionProxyHostImpl);
+};
+
+}  // namespace data_reduction_proxy
+
+#endif  // COMPONENTS_DATA_REDUCTION_PROXY_CONTENT_BROWSER_DATA_REDUCTION_PROXY_HOST_IMPL_H_