release ref on failing connectTCP

[WebFreak001]

fix #115

Unsure how this affects windows, but if the auto tests are also run on windows it should find any issue there. please test manually

status is refused in this case and it's not handled by the existing cases cancelling a connection, so the reference to the socket still exists and needs to be released by the caller here.

[s-ludwig]

It looks like this is an issue in eventcore. All other error codes result in the socket being closed, but ConnectionStatus.refused keeps it open (direct reason for the difference is that all other codes are generated immediately, while refused is an event loop event). I'll add a call to releaseRef right after the user callback has been invoked, so that the socket handle is still valid during the callback.

[s-ludwig]

Upon taking a closed look, the behavior in eventcore makes sense, because otherwise the handle already returned by connectStream would be silently invalidated. So fixing it here is the right thing to do after all.

It would be nice to get the test case to actually fail. The only way I see right now is to count the number of open files at the start and at the end of the test case (e.g. using getrlimit). I'd look into the Windows version of this.

[WebFreak001]

Can't we make the "get leaked handles" message as a public function in eventcore?

[s-ludwig]

Doing that properly would be a bit more involved, because the leaked handles may be scattered over multiple threads/drivers (in TLS-memory), so the first step would be a global registry for driver instances and thread-safe way to query leaked handles of foreign threads. The getrlimit variant would be a oneliner using iota/count on the other hand.

[s-ludwig]

I'll tackle the test additions in a separate branch.