reset "multipass" state when CONNECT request is done

[tilicho]

Usually, work with proxy using NTLM looks like this
(https://www.cisco.com/c/en/us/support/docs/security/web-security-appliance/117931-technote-ntml.html):
1. Client sends

HEADER: > CONNECT my.site.com:443 HTTP/1.1
Host: my.site.com:443
Proxy-Authorization: NTLM <tldr1>
Proxy-Connection: Keep-Alive

2. Proxy responds:
HEADER: < HTTP/1.1 407 Proxy Authentication Required
HEADER: < Proxy-Authenticate: NTLM <tldr2>

3. Client sends:
HEADER: > CONNECT my.site.com:443 HTTP/1.1
Host: my.site.com:443
Proxy-Authorization: NTLM <tldr3>

4. If everything is fine, proxy finally replies with http status 200
HEADER: < HTTP/1.1 200 Connection established

After that, client send original request through proxy (POST/GET/PUT/...).

---

We found interesting proxy from cisco, that performs some optimization in that conversation.
It looks like this:
1'. Client sends

HEADER: > CONNECT my.site.com:443 HTTP/1.1
Host: my.site.com:443
Proxy-Authorization: NTLM <tldr1>
Proxy-Connection: Keep-Alive

2'. Proxy immediatelly responds with http status 200:
HEADER: < HTTP/1.1 200 Connection established

This happens because proxy has remembered that client with specific ip address had passed ntlm authentication already.
So, proxy desides to pass client without performing long conversation.

And, in the case of such short ntlm conversation we found bug in curl.
If curl performed POST request with body through such proxy, after short ntlm convertation curl makes POST request WITHOUT BODY.

[bagder]

The same travis job has failed now three times (I restarted it twice) which might imply there's a problem.

When run event-driven test 89 seems to be able to get stuck. I've tried to re-run that locally but have not seen it happen for me: ./runtests.pl -e 89.

[bagder]

Probably a false positive since #3976 also saw the same problem occurring...

[bagder]

Thanks!