Revert "Revert of Moving gRPC support interfaces out of cronet and into a new component. (patchset …

components/cronet/ios/cronet_environment.cc

Index: components/cronet/ios/cronet_environment.cc
diff --git a/components/cronet/ios/cronet_environment.cc b/components/cronet/ios/cronet_environment.cc
index 0fef4af2e2266ab840e1b76a457f213ba763f5a6..a033691ae20c0dae3fd00fdd9e2572f6cec8a7cc 100644
--- a/components/cronet/ios/cronet_environment.cc
+++ b/components/cronet/ios/cronet_environment.cc
@@ -96,10 +96,6 @@ class CronetURLRequestContextGetter : public net::URLRequestContextGetter {
 
 namespace cronet {
 
-bool CronetEnvironment::IsOnNetworkThread() {
-  return network_io_thread_->task_runner()->BelongsToCurrentThread();
-}
-
 void CronetEnvironment::PostToNetworkThread(
     const tracked_objects::Location& from_here,
     const base::Closure& task) {
@@ -400,4 +396,12 @@ std::vector<uint8_t> CronetEnvironment::GetHistogramDeltas() {
   return data;
 }
 
+void CronetEnvironment::SetHostResolverRules(const std::string& rules) {

[mef, 2016/11/07 16:33:26]

Just to confirm my understanding, do we need to change host resolver rules in
order to specify actual port for the mapped host?

[Garrett Casto, 2016/11/07 17:23:11]

Yeah. The problem is that we need to specify two things for the
URLRequestContext, the fact that a particular hostname speaks QUIC, and the fact
that we want a particular hostname to resolve to a certain port. If it were just
the latter constraint, we could have the test specify the url as
"test.example.com:%d/path" and just fill in the port dynamically. However
because of the QUIC constraint this will fail because the net stack will try to
talk TCP to the port and fail. There doesn't seem to be a way to say that you
want all communication to a particular domain to be QUIC, only for a specific
origin. 

So I think that we need to update the URLRequestContexts, and doing it this way
seem to be the easiest route since MappedHostResolver is thread safe so we don't
need to jump threads.

+  host_resolver_rules_ = rules;
+  if (main_context_) {

[mef, 2016/11/07 17:26:38]

I think this is racy. :( 

It is possible that SetHostResolverRules is executed on the application thread
before CronetEnvironment::InitializeOnNetworkThread() gets executed on the
network thread.

Generally speaking, we shouldn't access |main_context_| and its members outside
of the network thread. Would it be better to post this to network thread?

+    static_cast<net::MappedHostResolver*>(main_context_->host_resolver())
+        ->SetRulesFromString(host_resolver_rules_);
+  }
+}
+
 }  // namespace cronet