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

net/socket/ssl_client_socket_openssl.cc

Index: net/socket/ssl_client_socket_openssl.cc
diff --git a/net/socket/ssl_client_socket_openssl.cc b/net/socket/ssl_client_socket_openssl.cc
index b6f6aec10afd1c473ceffc552b9a05f5b7b563a6..5c1d8f2d054d6e59fb4f1ac74237940677f8bff4 100644
--- a/net/socket/ssl_client_socket_openssl.cc
+++ b/net/socket/ssl_client_socket_openssl.cc
@@ -393,7 +393,7 @@ void SSLClientSocketOpenSSL::SetIsLeader() {
 
 void SSLClientSocketOpenSSL::OnSocketFailure() {
   if (is_leader_)
-    error_callback_.Run();
+    base::MessageLoopForIO::current()->PostTask(FROM_HERE, error_callback_);

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

IMPORTANT: please verify that this task should still be run if this object is
deleted.

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

By "this object" do you mean the SSLClientSocketOpenSSL that this method is
called on, or the SSLConnectJobMessenger that is bound to the callback? 

If you're referring to the socket, then yes the task should still be run even if
the socket is deleted. The callback is runng OnJobFailed, which doesn't actually
use the socket of the failed job. It just removes this socket from
connecting_sockets_, and then tells the next socket in
pending_sockets_and_callbacks_ to connect. 

If you're referring to the SSLConnectJobMessenger, as of now that won't be
deleted until the SSLConnectJobFactory is deleted. My understanding was that the
SSLConnectJobFactory should outlive all sockets because it's owned by socket
pool, so I don't think that the messenger being deleted should ever be a
problem?

Note that I do plan to change the handling of SSLConnectJobMessengers so that
they are deleted after all of their pending sockets have been told to connect.  

[Ryan Sleevi, 2014/07/09 22:40:37]

To be clear: The situation concerned is

Precondition:
Contents of MessageLoop
  Task1 - Run something that will eventually call OnSocketFailure
  Task2 - Shut things down

At T0, you run Task1, which schedules a new Task, Task3, to run error_callback_
At T1, Task2 runs, deleting everything
At T2, error_callback_ is now run, except the thing that created the
ErrorCallback may have gone away.

Wan-Teh's fundamental question was that if, as part of T1/Task2, this object is
deleted, is it still correct to call error_callback_?

The current design of the net/socket interfaces is that once an object is
destroyed, *no* callbacks for pending operations will be called. Which means
calling T2/error_callback_ would be a violation of that principle, because the
associated socket will have gone away.

 }
 
 void SSLClientSocketOpenSSL::GetSSLCertRequestInfo(