CHECK() if Windows non-blocking connect returns 0.

CHECK() if Windows non-blocking connect returns 0.

Non-blocking connect() on Windows is documented as always returning
WSAEWOULDBLOCK or another error.

There has been code in place to handle a 0 return value, but we have
no way to test whether it is correct or not.

Replace the code to handle a 0 return with a CHECK() call, to find out
whether a 0 result really can happen or not.

BUG=436634
TEST=net_unittests

Committed: https://crrev.com/2d53a9381e88eab543cc4c9fd122b0b1ed4f41d7
Cr-Commit-Position: refs/heads/master@{#326243}

[Adam Rice, 2015-04-21 10:01:36]

ricea@chromium.org changed reviewers:
+ mmenke@chromium.org

[Adam Rice, 2015-04-21 10:01:36]

+mmenke for OWNERS review. Please punt to someone else if appropriate.

[mmenke, 2015-04-21 13:10:45]

LGTM

[Adam Rice, 2015-04-22 06:49:49]

The CQ bit was checked by ricea@chromium.org

[commit-bot: I haz the power, 2015-04-22 06:50:01]

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

[commit-bot: I haz the power, 2015-04-22 08:03:26]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2015-04-22 08:04:20]

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

[Adam Rice, 2015-04-23 14:05:33]

A revert of this CL (patchset #1 id:1) has been created in
https://codereview.chromium.org/1076093006/ by ricea@chromium.org.

The reason for reverting is: It's crashing in Canary builds. We have probably
gained enough data now, so I'm reverting..