Makes waiting SSLConnectJobs use the message loops to resume their connection.

net/socket/ssl_client_socket_pool.cc

Index: net/socket/ssl_client_socket_pool.cc
diff --git a/net/socket/ssl_client_socket_pool.cc b/net/socket/ssl_client_socket_pool.cc
index 3032a08bf49203ef17ae9d8565de00a437b79013..39481748424a8f94fba0f74840584d3ad7336ff1 100644
--- a/net/socket/ssl_client_socket_pool.cc
+++ b/net/socket/ssl_client_socket_pool.cc
@@ -135,7 +135,7 @@ void SSLConnectJobMessenger::OnJobFailed() {
   connecting_sockets_.push_back(ssl_socket);
   pending_sockets_and_callbacks_.EraseFirstEntry();
   MonitorConnectionResult(ssl_socket);
-  cb.Run();
+  base::MessageLoopForIO::current()->PostTask(FROM_HERE, cb);

[wtc, 2014/07/08 17:37:03]

IMPORTANT: please make sure the task won't run if |ssl_socket| is destroyed
after the task is posted but before the message loop is ready to run the task.

[Ryan Sleevi, 2014/07/08 19:36:53]

Note: You should not use base::MessageLoopForIO directly.

The "old" path was using base::MessageLoop::current() [which always returns the
MessageLoop of the current thread, and you're always guaranteed that this thread
will be the IO thread by virtue of these classes being single threaded]

The "new" path is to use ThreadTaskRunnerHandle::Get()->PostTask() instead.

However, as Wan-Teh mentioned, we need to ensure that this callback is safe to
run even when the socket is deleted. We should be able to ensure this by
ensuring the callback, when registered (and later returned by
GetFirstCallback()) uses a WeakPtr.

Another thing to consider is to actually schedule a callback to grab the first
callback, rather than grabing it on line 131.

imagine you have sockets 1, 2, and 3 - with 1 being the leader.

If 1 connects, and you decide to start connecting 2, you could PostTask, but
then 2 could be deleted.
1) If 2 is deleted, you need to make sure the unregistration code can handle
when 2 is no longer in pending_sockets_and_callbacks (eg: all the state in line
113-136)
2) If 2 is deleted, what you want is to allow 3 to resume, not 2.

For this reason, I'd suggest you actually do a PostTask that runs a method on
the SSLCJM, which then does what you do on lines 129-138, and use an (internal
only) weakptr to the SSLCJM.

This will ensure that if 2 is deleted, by the time the CB runs, 3 is what is
treated as the leader (line 134) and the CB that is run.

[mshelley, 2014/07/09 21:53:06]

So I think the issue that you're referring to could happen if socket 1 fails to
connect -- if socket 1 connects, then all of the pending socket's callbacks will
be run regardless of whether one of them fails (i.e. there is no leader). 

To make sure that I understand what you're suggesting: I could have OnJobsFailed
post a task with callback to another SSLCJM method, which would essentially do
the same thing as OnJobsFailed, except it would look for the first socket in
pending_sockets_and_callbacks that had not been deleted (not just the first
socket), and then treat that socket as the leader and directly run its callback.

 }
 
 // Timeout for the SSL handshake portion of the connect.