gh-156057: Wrap compression library exceptions in tarfile.ReadError

[JMak-Security]

Fixes gh-156057.

The bug

TarFile.extractfile() reads a member's payload through _FileInFile.read(), which calls the underlying compressed fileobj.read() (a gzip.GzipFile/bz2.BZ2File/lzma.LZMAFile/zstd.ZstdFile for seekable-mode r:gz/r:bz2/r:xz/r:zst archives) with no exception handling. If the member's compressed data is corrupted after the header was already read successfully (rather than at initial archive-open time), the codec's own exception - zlib.error, OSError from bz2, lzma.LZMAError, or zstd.ZstdError - leaks straight through to the caller instead of being wrapped in tarfile.ReadError.

The streaming-mode (r|gz etc.) code path already handles this correctly: _Stream sets a self.exception attribute to the specific codec's error type and catches it around its own decompress() calls. The seekable-mode path via _FileInFile had no equivalent.

The fix

Give TarFile (and _FileInFile) the same per-codec exception attribute pattern already used by _Stream:

• TarFile.exception defaults to OSError (correct for bz2, and for uncompressed tar mode where it's simply unused).
• gzopen()/xzopen()/zstopen() set it to the specific type (zlib.error, LZMAError, ZstdError) after a successful open, mirroring what they already do for t._extfileobj.
• ExFileObject.__init__ passes tarfile.exception through to _FileInFile, which now wraps its fileobj.read() call and re-raises as tarfile.ReadError.

Verification

Reproduced the leak against current main for gzip, bzip2, and xz (couldn't test zstd locally - no compression.zstd module in the Python available here) using a corrupted-mid-stream archive for each, confirming all three previously leaked the raw codec exception. Same test against the patched version confirms all three now raise tarfile.ReadError instead. Also ran a full write/read/extract round-trip across all four compression modes (uncompressed, gzip, bzip2, xz) to confirm no regression in normal operation.

[Aniketsy]

@JMak-Security thanks for the PR

Could you add tests for this ?

[JMak-Security]

@Aniketsy, sure, I'll get back to you later when I add the tests.

[JMak-Security]

@Aniketsy done! Added Lib/test/test_tarfile.py::FileInFileExceptionWrappingTest (direct unit tests on _FileInFile.read(): one confirming it wraps the configured exception type into ReadError, one confirming an unconfigured exception type still propagates unwrapped) and GzipExtractfileWrapsCompressionErrorTest (an integration test confirming the real gzopen() wiring surfaces a zlib.error raised mid-extraction as tarfile.ReadError).

I verified these against both states of Lib/tarfile.py: they fail on the pre-fix source (TypeError: unexpected keyword argument 'exception' for the unit tests, and the raw uncaught zlib.error for the integration test) and pass on the post-fix source, so they should meaningfully guard this behavior going forward.