Considering treating ECONNRESET as an error case #934
Description
Kestrel has treated an ECONNRESET read the same as EOF pretty much since the beginning, and I don't think this decision ha really been questioned before. Like how we were improperly handling 0 status back then, I'm starting to think that treating ECONNRESET different from other read errors might also be a mistake.
First, the fact that we don't even log ECONNRESET differently than EOF, makes it difficult to diagnose issues like #932. I believe that issue stems from a connection reset, but I can't really be certain. I don't think the problem is just logging though.
Right now, if ECONNRESET happens mid request, this will often lead to a BadHttpRequestException due to invalid headers, content length, chunking, etc... If the request becomes invalid, the issue is somewhat mitigated, since it at least it leads to some sort of read error. It would still be nicer if a ECONNRESET UvException/IOException was surfaced instead when that is the root cause of the bad request.
HTTP/1.0 and Connection: close requests are scarier. Instead of there being an error, the request is simply truncated. This could cause apps to misbehave in subtle ways.
It shouldn't be a concern that clients using ECONNRESET as a "normal" means of closing the request, since this would prevent the client from ever receiving the response. If an ECONNRESET is received after the request is completed but before the response is written, the application won't see any exceptions unless it passes the RequestAborted token to calls to Write (#566).
If we make this change, we can also remove the platform specific logic to determine the error code. (#764).