Tweak AndroidMessageHandler behavior for WCF support

[grendello]

Context: #7230
Context: dotnet/runtime#80935

When a WCF application receives compressed content that is automatically
decompressed in AndroidMessageHandler, it will most of the time fail
to properly read the response, cutting reading of the decompressed
content short. The reason for this is that when AndroidMessageHandler
creates a wrapper decompression stream, it does not update the
Content-Length to match the length of the decoded content, because it
doesn't have a way to know what the length is without first reading the
stream to the end, and that might prevent the end user to read the
content. Additionally, I think the Content-Length header should
reflect the original content length, for the end user to be able to
interpret the response as it was sent.

WCF, on the other hand, looks at the Content-Length header and, if
found, it takes its value and reads only this many bytes from the
content stream and no more - it will almost always result in short reads
and failure to correctly interpret the response.

I implemented this workaround which makes AndroidMessageHandler behave
the same way as other handlers implemented in the BCL. What they do in
this situation, is to remove the Content-Length header, making WCF
read stream to the end. Additionally, the clients remove the compressed
content encoding identifier from the Content-Encoding header.

As a bonus, this commit also adds support for decompression of responses
compressed with the Brotli compression (using the br encoding ID in
the Content-Encoding header)

[simonrozsival]

The code looks good to me. Could you please add a test that would get a response from https://httpbin.org/gzip and https://httpbin.org/brotli and check that it works properly?

[jonathanpeppers]

Is there a way to avoid the new assembly? It seems like any app that uses HttpClient will now bring in BrotliStream? Maybe that is OK?

If we added some feature flag, then you'd have to enable a setting to use it. I'm not sure if that is better.

[grendello]

The assembly is so tiny that I don't think it's problem, especially that the native library is 700k and included anyway (it contains all the System.IO.Compression native code to handle Deflate, GZip and Brotli).

[grendello]

@simonrozsival turns out the test cannot check whether the Content-Length header has been removed. We remove it in the message handler, but HttpClient adds it back, with the value specifying the size of uncompressed content.

[simonrozsival]

@grendello I see. That's not what I was expecting, but it makes sense. Let's add an assert that verifies that the number of bytes in the response content is equal to the value returned by the ContentLength property. That'll confirm that this PR fixes the WCF issue.

[simonrozsival]

It's strange that it's failing in some test configurations and passing in other, especially for "gzipped". Maybe we could dump the responseBody to see if the response from the server is what we expect?

Is it possible that sometimes the server doesn't respond with a 200 (because of some rate limiting)? We should ignore the test result if the response is 4xx or 5xx.

[grendello]

Yeah, I found it curious too. Rate limiting is a possibility, definitely. It would be great if we could host httpbin somewhere, probably need to ask around about this.

I ran the tests many times locally and always got the valid answer, so the principle of the test is solid. I will add check for 4xx and 5xx errors.

[jonpryor]

Context: https://github.com/xamarin/xamarin-android/issues/7230
Context: https://github.com/dotnet/runtime/issues/80935

When a WCF application invokes an endpoint which returns compressed
content, and `AndroidMessageHandler` is doing the network requests
([the default when `$(UseNativeHttpHandler)`=True][0]):

	var soapClient = new WebServiceSoapClient(WebServiceSoapClient.EndpointConfiguration.WebServiceSoap);
	//Async test
	var helloResponse = await soapClient.HelloWorldAsync();

then the method will throw:

	The formatter threw an exception while trying to deserialize the message: There was an error while trying to deserialize parameter http://tempuri.org/:HelloWorldResponse.
	---> There was an error deserializing the object of type ServiceReference1.HelloWorldResponseBody. Unexpected end of file. Following elements are not closed: HelloWorldResult, HelloWorldResponse, Body, Envelope. Line 1, position 298.
	   at System.Runtime.Serialization.XmlObjectSerializer.ReadObjectHandleExceptions(XmlReaderDelegator reader, Boolean verifyObjectName, DataContractResolver dataContractResolver)
	   at System.Runtime.Serialization.XmlObjectSerializer.ReadObjectHandleExceptions(XmlReaderDelegator reader, Boolean verifyObjectName)
	   at System.Runtime.Serialization.DataContractSerializer.ReadObject(XmlDictionaryReader reader, Boolean verifyObjectName)
	   at System.ServiceModel.Dispatcher.DataContractSerializerOperationFormatter.PartInfo.ReadObject(XmlDictionaryReader reader, XmlObjectSerializer serializer) in /_/src/System.Private.ServiceModel/src/System/ServiceModel/Dispatcher/DataContractSerializerOperationFormatter.cs:line 657
	   at System.ServiceModel.Dispatcher.DataContractSerializerOperationFormatter.PartInfo.ReadObject(XmlDictionaryReader reader) in /_/src/System.Private.ServiceModel/src/System/ServiceModel/Dispatcher/DataContractSerializerOperationFormatter.cs:line 652
	   at System.ServiceModel.Dispatcher.DataContractSerializerOperationFormatter.DeserializeParameterPart(XmlDictionaryReader reader, PartInfo part, Boolean isRequest) in /_/src/System.Private.ServiceModel/src/System/ServiceModel/Dispatcher/DataContractSerializerOperationFormatter.cs:line 521

The reason for this is that when `AndroidMessageHandler` creates a
wrapping decompression stream, it does not update `Content-Length` to
match the length of the decoded content, because it doesn't have a
way to know what the length is without first reading the stream to the
end, and that might prevent the end user to read the content.
(Additionally, I think the `Content-Length` header should reflect the
*original* content length, for the end user to be able to
interpret the response as it was sent.)

WCF, on the other hand, looks at the `Content-Length` header and, if
found, takes the value and reads only that many bytes from the content
stream and no more, which will almost always result in short reads and
failure to correctly interpret the response.

Workaround this issue by making `AndroidMessageHandler` behave the
same way as other handlers implemented in the BCL.  What they do in
this situation is remove the `Content-Length` header, making WCF
read the stream to the end.  Additionally, the clients remove the
compressed content encoding identifier from the `Content-Encoding`
header.

	var handler = new AndroidMessageHandler {
	    AutomaticDecompression = DecompressionMethods.All
	};
	var client    = new HttpClient (handler);
	var response  = await client.GetAsync ("https://httpbin.org/gzip");
	// response.Content.Headers won't contain Content-Length,
	// and response.Content.Headers.ContentEncoding won't contain `gzip`.

As a bonus, also adds support for decompression of responses
compressed with the `Brotli` compression which use the `br` encoding
ID in the `Content-Encoding` header.

[0]: https://learn.microsoft.com/en-us/dotnet/core/deploying/trimming/trimming-options?pivots=dotnet-7-0