SocketsHttpHandler should replace received new lines in headers with spaces

[MihaZupan]

From https://www.rfc-editor.org/rfc/rfc9110.html#section-5.5-5

Field values containing CR, LF, or NUL characters are invalid and dangerous, due to the varying ways that implementations might parse and interpret those characters; a recipient of CR, LF, or NUL within a field value MUST either reject the message or replace each of those characters with SP before further processing or forwarding of that message. Field values containing other CTL characters are also invalid; however, recipients MAY retain such characters for the sake of robustness when they appear within a safe context (e.g., an application-specific quoted string that will not be processed by any downstream HTTP parser).

With HTTP/1.1 it's not possible for a user of HttpClient to observe new lines in the response headers collection since the new line itself is a protocol-level separator.
When parsing HTTP/1.1 line folds, we do replace the new lines with spaces.

runtime/src/libraries/System.Net.Http/src/System/Net/Http/SocketsHttpHandler/HttpConnection.cs

Lines 1216 to 1219 in a7bd51e

	// Found an obs-fold (CRLFHT/CRLFSP).
	// Replace the CRLF with SPSP and keep looking for the final newline.
	valueIterator[crOrLfIdx] = (byte)' ';
	valueIterator[lfIdx] = (byte)' ';

But when using HTTP/2 or HTTP/3, we don't check for such characters.

We could choose to also relace the NUL char on HTTP/1.1 as suggested by RFC. Related: #116634

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/ncl
See info in area-owners.md if you want to be subscribed.