bug: Can't read GCS files due to Decompressive Transcoding

[amos-osmos]

Describe the bug

We have some files which are gzip encoded at rest in GCS. Thanks to Decompressive transcoding, when getting metadata about a file the compressed byte count will be returned, but when the file itself is retrieved it will be uncompressed and so the total byte count will be higher.

This interacts poorly with this PR: #4690 where the two values mentioned above are compared and we keep hitting reader got too much data.

Steps to Reproduce

I'm working on providing an actual repro but running into difficulties with permissions.

1. Have a file gzip encoded on GCS, with object metadata Content-Encoding set to gzip.
2. Now, build an operator of type opendal::types::operator::operator::Operator and call operator.read()
3. What currently happens is an opendal::Error as the Result that prints to:

Unexpected (permanent) at  => reader got too much data

Context:

expect: <compressed byte count>

actual: <uncompressed byte count>

Expected Behavior

An Ok Result with the contents of the file.

Additional Context

No response

Are you willing to submit a PR to fix this bug?

• Yes, I would like to submit a PR.

[Xuanwo]

We will bypass the content length check if the response includes content-encoding or it doesn't have content-length header:

opendal/core/src/raw/http_util/client.rs

Lines 126 to 131 in 309d3eb

	let content_length = if is_head || parse_content_encoding(resp.headers())?.is_some() {
	None
	} else {
	parse_content_length(resp.headers())?
	};

I will try to reproduce this.