HTTP::Client spec: don't write server response if expecting read timeout

[asterite]

Fixes #7401

I found out that the problem was in the "tests read_timeout" spec. This fixes it but I'm not entirely sure why the exception happens.

What I think happens is:

• the client is set a read timeout, and it will timeout
• the server is said to wait for more time than that of the read timeout and then write a response
• by the time the server gets to write the response, the client's socket might be already closed because the GC already finalized it

At least I couldn't reproduce it with GC_DONT_GC=1 (but then it failed because of too many open file requests), so I'm not sure. But I think my logic above is correct.

In this PR, when we expect a read timeout to happen we don't even bother instructing the server to write a response because that doesn't matter anymore.

However, this leads me to think... if I write an HTTP server and I accept a request and the client closes the socket before I get to write the response... an exception will be raised and it will be printed in the server's spawn handling that request. Is that OK? How do other languages handle this?

[bew]

if I write an HTTP server and I accept a request and the client closes the socket before I get to write the response... an exception will be raised and it will be printed in the server's spawn handling that request. Is that OK?

That's what I would expect at least..

[asterite]

Ugh, that failure in darwin... come on, CI, I'm trying my best here, don't give me new errors...

[asterite]

For history purposes, this is the darwin build that failed: https://circleci.com/gh/crystal-lang/crystal/18231?utm_campaign=vcs-integration-link&utm_medium=referral&utm_source=github-build-link

I'll re-run it now.

[straight-shoota]

I'm pretty sure the immediate issue should be fixed by #7197.

[asterite]

Another one to investigate, a Nil assertion failed in signal_spec.cr: https://circleci.com/gh/crystal-lang/crystal/18298?utm_campaign=vcs-integration-link&utm_medium=referral&utm_source=github-build-link

[straight-shoota]

That's already tracked in #7243

[asterite]

We can probably merge this PR first, which is really small, and then focus on reviewing #7197, which is much larger and also is currently failing on my machine.

[straight-shoota]

I'm not sure if this would really be required to keep in the long run, but it's fine by me.