Mojo: Fix Mac Mach port brokering race

https://crrev.com/0e45f8023 somehow lost this logic before
landing, probably during extensive debugging churn. :{

Without this, it's possible for Mach port transfer to fail
when sending to a new process. Seems to have gone undetected
in production so far, but https://crrev.com/3e126191 managed
to trip over it consistently in ipc_tests.

Bug: 753541
Change-Id: I835dc5f26326718af678acd6199c285d709b9040
Reviewed-on: https://chromium-review.googlesource.com/1134079Reviewed-by: Reilly Grant <reillyg@chromium.org>
Commit-Queue: Ken Rockot <rockot@chromium.org>
Cr-Commit-Position: refs/heads/master@{#574418}

mojo/core/channel_posix.cc

@@ -144,8 +144,19 @@ class ChannelPosix : public Channel,
     // must also have the ability to extract a send right from the ports that
     // are already attached.
     MachPortRelay* relay = Core::Get()->GetMachPortRelay();
-    if (relay && remote_process().is_valid() && message->has_mach_ports())
+    if (relay && remote_process().is_valid() && message->has_mach_ports()) {
+      if (relay->port_provider()->TaskForPid(remote_process().get()) ==
+          MACH_PORT_NULL) {
+        // We also need to have a task port for the remote process before we can
+        // send it any other ports. If we don't have one yet, queue the message
+        // until OnProcessReady() is invoked.
+        base::AutoLock lock(task_port_wait_lock_);
+        pending_outgoing_with_mach_ports_.emplace_back(std::move(message));
+        return;
+      }
+
       relay->SendPortsToProcess(message.get(), remote_process().get());
+    }
 #endif
 
     bool write_error = false;