[PR #12674/e8832aee backport][3.14] Fix ZLibDecompressor dropping data past the first gzip member

[patchback]

This is a backport of PR #12674 as merged into master (e8832ae).

What do these changes do?

When a response body contains concatenated gzip members (e.g. a server that produces one gzip member per write call, as nginx does under certain configs), zlib.decompressobj sets eof and stores the remaining bytes in unused_data after it finishes the first member. decompress_sync() wasn't checking unused_data at all, so every member after the first was silently discarded. The caller got truncated output with no error.

The fix applies the same while eof and unused_data loop that ZSTDDecompressor already uses for multi-frame zstd streams. Each iteration creates a fresh decompressor and feeds it the leftover bytes, accumulating output across all members. max_length is tracked and honoured across the loop.

Also added unused_data to ZLibDecompressObjProtocol so the attribute is properly typed, and three tests that mirror the existing ZSTD multi-frame test suite.

Are there changes in behaviour for the end user?

Yes — responses with concatenated gzip members now decompress fully instead of being silently truncated at the first member boundary.

Related issue number

Fixes #7157

Checklist

• I think the code is well written
• Unit tests for the changes exist
• Documentation reflects the changes
• make fmt has been run N/A (formatting only)
• All the tests pass
• Changelog entry added
• Added myself to CONTRIBUTORS.txt

Drafted with Claude Sonnet 4.6; reviewed by Ashutosh-177.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 98.18%. Comparing base (8e2f232) to head (2e89d6b).
✅ All tests successful. No failed tests found.

Additional details and impacted files

@@           Coverage Diff           @@
##             3.14   #12745   +/-   ##
=======================================
  Coverage   98.18%   98.18%           
=======================================
  Files         135      135           
  Lines       47667    47750   +83     
  Branches     2558     2563    +5     
=======================================
+ Hits        46801    46884   +83     
  Misses        683      683           
  Partials      183      183           

Flag	Coverage Δ
CI-GHA	98.23% <100.00%> (+<0.01%)	⬆️
OS-Linux	98.00% <100.00%> (+<0.01%)	⬆️
OS-Windows	95.66% <100.00%> (+<0.01%)	⬆️
OS-macOS	97.19% <100.00%> (+<0.01%)	⬆️
Py-3.10	97.38% <100.00%> (+0.01%)	⬆️
Py-3.11	97.66% <100.00%> (-0.01%)	⬇️
Py-3.12	97.74% <100.00%> (-0.01%)	⬇️
Py-3.13	97.72% <100.00%> (+<0.01%)	⬆️
Py-3.14	97.83% <100.00%> (+<0.01%)	⬆️
Py-3.14t	96.81% <100.00%> (+<0.01%)	⬆️
Py-pypy-3.11	96.66% <100.00%> (+<0.01%)	⬆️
VM-macos	97.19% <100.00%> (+<0.01%)	⬆️
VM-ubuntu	98.00% <100.00%> (+<0.01%)	⬆️
VM-windows	95.66% <100.00%> (+<0.01%)	⬆️
cython-coverage	38.24% <58.33%> (+0.03%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[codspeed-hq]

Merging this PR will not alter performance

✅ 72 untouched benchmarks
⏩ 7 skipped benchmarks¹

---

_{Comparing patchback/backports/3.14/e8832aee7f694979292740b9b56a9c98fb0afc1a/pr-12674 (2e89d6b) with 3.14 (8e2f232)}

Footnotes

1. 7 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩