More robust error handling

[chansikpark]

Crossing some t's and dotting some i's following #2260, I decided to try this suggestion from Copilot:

It’s also useful to add a test where the client continues sending a large body and the server immediately returns 414 and closes the socket.

I found that the client SIGPIPEs. And even after handling these, the response object doesn't get populated when the socket is closed mid-transfer (ie for sufficiently large transfers).

So I made the following changes:

• Check if socket is alive before waiting to write to it to prevent SIGPIPE
• Consume SIGPIPE on client
• Client reads response line and headers after bad request before returning

[chansikpark]

I'll see if I can do a little more due dilligence before marking for review.

Also

Move one basic test assertion out of WIN32-only block

Should be

Move one basic test assertion out of non-WIN32 block

[thbeu]

A C/C++ library shall not call signal.

[chansikpark]

I'd been wondering why eg the README has this note:

If your program needs to avoid being terminated on SIGPIPE, the only fully general way might be to set up a signal handler for SIGPIPE to handle or ignore it yourself.

While the server code consumes SIGPIPE.. :

cpp-httplib/httplib.h

Lines 7322 to 7328 in 4b2b851

	inline Server::Server()
	: new_task_queue(
	[] { return new ThreadPool(CPPHTTPLIB_THREAD_POOL_COUNT); }) {
	#ifndef _WIN32
	signal(SIGPIPE, SIG_IGN);
	#endif
	}

In any case, I'd concede that the other two changes probably make the client-side signal unnecessary for what I was trying to do. Been meaning to play around a little more to better understand what I'm doing. Will revert particular change in the meantime.