add support for additional decoders

[codeboten]

This provides the ability to add support for compression types which are not supported in core, to be supported by individual components.

This change addresses an issue caused by #7927, which prevents receivers that use confighttp from adding support for their content-encoding types easily. They still can by implementing an error handler, but that seems messy.

An alternative to this PR is to not return an error for an unsupported encoding type as was the case before #7927

If the approach is acceptable, I will add the unit tests and changelog

[codecov]

Codecov Report

Patch coverage: 94.00% and project coverage change: +0.05 🎉

Comparison is base (8278824) 90.90% compared to head (abf444a) 90.96%.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #7977      +/-   ##
==========================================
+ Coverage   90.90%   90.96%   +0.05%     
==========================================
  Files         300      300              
  Lines       15074    15090      +16     
==========================================
+ Hits        13703    13726      +23     
+ Misses       1097     1091       -6     
+ Partials      274      273       -1     

Impacted Files	Coverage Δ
config/confighttp/compression.go	84.00% <93.02%> (+1.77%)	⬆️
config/confighttp/confighttp.go	92.17% <100.00%> (+4.31%)	⬆️

☔ View full report in Codecov by Sentry.
📢 Do you have feedback about the report comment? Let us know in this issue.

[tigrannajaryan]

An alternative to this PR is to not return an error for an unsupported encoding type as was the case before #7927

I think reverting to the wrong behavior is probably not what we want. Let's go forward with your PR. The question I have is whether there is a need for custom decoders or we just need to add "snappy" for all?

[codeboten]

I think reverting to the wrong behavior is probably not what we want. Let's go forward with your PR. The question I have is whether there is a need for custom decoders or we just need to add "snappy" for all?

Adding snappy would address the one case failing in contrib at the moment. I've not looked for additional cases, though @jpkrohling pointed out in a DM that this would allow anyone wanting to offer alternative decoders even for supported encodings could do so w/ this functionality

[jpkrohling]

Looks good to me, but I would love to have another test for snappy.

[jpkrohling]

Would it be asking too much to add an explicit test for snappy, as this is the one failing for existing receivers?

[codeboten]

I could add one, but it would essentially be a duplicate of the "UnsupportedCompression" test here:

opentelemetry-collector/config/confighttp/compression_test.go

Lines 185 to 189 in ec033ca

	name: "UnsupportedCompression",
	encoding: "nosuchcompression",
	reqBody: bytes.NewBuffer(testBody),
	respCode: http.StatusBadRequest,
	respBody: "unsupported Content-Encoding: nosuchcompression\n",

[jpkrohling]

My idea is that it would replace the "custom-encoding" test case with a real implementation, and it would be converted into a test that overrides an existing encoding once snappy is added. In any case, this isn't a blocker.

[codeboten]

I'll add this in a follow up PR since this is blocking contrib :)