Fix refcounted FD leak in HTTPClient

[tchaloupka]

I've observed that newly added condition m_conn.waitForDataEx(0.seconds) returns noMoreData even for EAGAIN and so leads to disconnects before the new request.
But there is still m_stream set (TLS) which were not destroyed and so there is FD refcount leak.
Calling disconnect that handles the stream too worked for me.

[tchaloupka]

TravisCI fail seems unrelated

[s-ludwig]

Thanks, this should be the right thing to do in any case and looks like it fixed a serious resource leak.

The wrong behavior of waitForDataEx(0.seconds) looks serious as well, tough. On which OS did you observe this?

[tchaloupka]

I've tested it on Fedora Linux 31, kernel 5.8.11-100.fc31.x86_64

[tchaloupka]

First I thought it is some problem in ConnectionPool but basically every new HTTP request over HTTPS ended up with connection close, handle leak and new connection.
I had to add some logging to socket creations, errors handling (to see actual system errno codes), refcounting increments/decrements and figured this out.

[tchaloupka]

This is basically the output of each client request:

[2020-10-14 15:37:55.113 main(AxlN) trc] returning HTTPClient connection 0 of 2, addr=7FF7AC69B6E0
[2020-10-14 15:37:55.113 main(AxlN) trc] Socket 139, read 0 bytes: wouldBlock
[2020-10-14 15:37:55.113 main(AxlN) trc] HTTPClient: doRequest close(): fd=139
releaseRef(139): 1, base=0 << should be 0
addRef(143): 3
[2020-10-14 15:37:55.122 main(AxlN) trc] connectTCP: fd=143, addr=192.168.0.142:9100
...

And then the leak:

> sudo lsof -a -p <pid> | grep "protocol: TCP"
prog  797620 tomas  139u     sock                0,8       0t0 59183873 protocol: TCP

[s-ludwig]

Okay, I've pushed a fix to vibe-core now: vibe-d/vibe-core#232

AFAICS, the keep-alive logic runs smoothly now, except that the retry-loop doesn't really work as intended, as a connection failure will throw an exception, causing the loop to get canceled.