Plumbing for TCP FastOpen for SSL sockets.

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 e54f79c929cee2b2eacb398bfa8896bcc64b212b..90a28cda1bca98e50bec1451e61bbe9ec07f7d0d 100644
--- a/net/socket/ssl_client_socket_pool.cc
+++ b/net/socket/ssl_client_socket_pool.cc
@@ -307,6 +307,9 @@ int SSLConnectJob::DoTransportConnect() {
   transport_socket_handle_.reset(new ClientSocketHandle());
   scoped_refptr<TransportSocketParams> direct_params =
       params_->GetDirectConnectionParams();
+  // Enable TCP FastOpen for SSL socket.
+  // TODO (jri): Finch trial this.
+  direct_params->enable_use_tcp_fastopen();

[mmenke, 2014/08/13 15:03:07]

Hrm...It looks like nothing else modifies these params after construction. 
Given that they're refcounted as well, that makes me a little nervous.  It's
theoretically possible for the same params to be used for multiple calls to this
(Does it happen?  Maybe with multiple preconnects?  Which will still work, but
that makes me nervouse).

I see two ways around this:  Create a new params object here, or move this logic
into net/socket/client_socket_pool_manager.cc.  The latter may be the better
option - that's where we create the parameters in the first place, though it is
rather a mess.

[Jana, 2014/08/14 06:35:31]

I see... I understand, and I agree. I've modified client_socket_pool_manager to
do this with a new TransportSocketParams object -- PTAL. I would appreciate a
careful read of that code... I don't think I'm breaking anything but a couple of
more pairs of eyes are definitely helpful!

   return transport_socket_handle_->Init(group_name(),
                                         direct_params,
                                         priority(),