fix: remove double logging of BadHttpRequest errors

[davhdavh]

remove double logging of BadHttpRequest errors

Description

SetBadRequestState already logs the error at debug level (where it belongs).
There is no reason to also log it as an application error (at error level), when it isn't an application error, but an IO error.

Fixes #23949

[adityamandaleeka]

This doesn't actually fix #23949 (which is about the error occurring at all, not about the fact that it's logged as an application error).

[davhdavh]

Depends on your point of view.
It is absolutely correct to throw the exception when a connection error occurs while reading the body.
Now problem is if it an IO exception or Cancelled exception. IMHO, the error happens on IO, so it should be an IO error. And others must have agreed for the problem to stick around for many years.
This PR fixes the fact that the IO exception is logged as an application error, when it is not.
That removes it from normal devs logs, and thus there is no reason to have a bug for it, except perhaps a different bug that goes back to discuss if this should be an IO exception or Cancelled exception.

[amcasey]

@davhdavh I find tratcher's argument, that throwing makes logical sense and the caller should do more to suppress the effects, persuasive and I'm not sure I understand the distinction you're drawing between IO exceptions and Cancelled exceptions. Can you please elaborate on why this is the appropriate fix for #23949?

In particular, are all BadHttpRequestExceptions client errors that a server owner wouldn't find interesting? (From the bug, it sounds like it happens under load, suggesting the server is involved.) And what other effects does not setting _applicationError have? It seems like it might impact keep-alive?

[amcasey]

Closing without prejudice - feel free to create a new one if you have new data or arguments.