Remove LogContainsSSLConnectEndEvent.

Remove LogContainsSSLConnectEndEvent.

It was added in https://codereview.chromium.org/3531019 to account for False
Start corking logic. That logic has since been removed, so there is no need to
account for it anymore.

Also remove a TODO to use SSL_RestartHandshakeAfterCertReq. There's not much
point since we'll still need a timeout with new socket codepath anyway.

BUG=none

Committed: https://crrev.com/e9f16dac4e4720220557b1bce6cc8edf9af2745f
Cr-Commit-Position: refs/heads/master@{#332289}

[davidben, 2015-06-01 19:15:16]

davidben@chromium.org changed reviewers:
+ rsleevi@chromium.org

[davidben, 2015-06-01 19:15:16]

Noticed this while poking at the VerifyReturnChainProperlyOrdered suppression.

[Ryan Sleevi, 2015-06-01 19:41:04]

LGTM with comment nit

https://codereview.chromium.org/1162323002/diff/1/net/socket/ssl_client_socke...
File net/socket/ssl_client_socket_unittest.cc (right):

https://codereview.chromium.org/1162323002/diff/1/net/socket/ssl_client_socke...
net/socket/ssl_client_socket_unittest.cc:1154: // two.
Write the comment without pronouns. It's cleaner that way

// Because the handshake is aborted during the CertificateRequest, the server
may still send data (notably,
// the ServerHelloDone) after the error is returned.  As a result, the
SSL_CONNECT may not be the last
// entry. See http://crbug.com/54445. Because of this, use
ExpectLogContainsSomewhere, rather than
// LogContainsEndEvent, to avoid assuming particular details about the read
(e.g. assuming there will
// only be one extra read, when there might be more)

[davidben, 2015-06-01 21:13:13]

https://codereview.chromium.org/1162323002/diff/1/net/socket/ssl_client_socke...
File net/socket/ssl_client_socket_unittest.cc (right):

https://codereview.chromium.org/1162323002/diff/1/net/socket/ssl_client_socke...
net/socket/ssl_client_socket_unittest.cc:1154: // two.
Done.

Actually, I suspect this comment is now silly. As of
https://chromiumcodereview.appspot.com/11633021, I'm not sure this is possible.
Except that memio_PutReadResult doesn't clear read_requested, so it might be
relying on pumping the state machine a second time before calling BufferRecv.
Which is probably sound but maybe does weird things around renego with reads and
writes flying?

I'm not sure. I've added a TODO so as not to bog down this CL and will dig in a
follow-up.

[davidben, 2015-06-01 21:16:20]

The CQ bit was checked by davidben@chromium.org

[davidben, 2015-06-01 21:16:20]

The patchset sent to the CQ was uploaded after l-g-t-m from rsleevi@chromium.org
Link to the patchset: https://codereview.chromium.org/1162323002/#ps20001
(title: "sleevi comment")

[commit-bot: I haz the power, 2015-06-01 21:17:29]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1162323002/20001

[commit-bot: I haz the power, 2015-06-01 23:51:43]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-06-01 23:51:43]

Try jobs failed on following builders:
  mac_chromium_compile_dbg_ng on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_comp...)

[davidben, 2015-06-01 23:56:23]

On 2015/06/01 23:51:43, commit-bot: I haz the power wrote:
> Try jobs failed on following builders:
>   mac_chromium_compile_dbg_ng on tryserver.chromium.mac (JOB_FAILED,
>
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_comp...)

Looks unrelated

[davidben, 2015-06-01 23:56:30]

The CQ bit was checked by davidben@chromium.org

[commit-bot: I haz the power, 2015-06-01 23:59:20]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1162323002/20001

[commit-bot: I haz the power, 2015-06-02 01:04:05]

Committed patchset #2 (id:20001)

[commit-bot: I haz the power, 2015-06-02 01:04:58]

Patchset 2 (id:??) landed as
https://crrev.com/e9f16dac4e4720220557b1bce6cc8edf9af2745f
Cr-Commit-Position: refs/heads/master@{#332289}