tarfile improvements

[srittau]

• Use Literal for mode.
• Don't explicitly derive from Iterable.
• Use imports from collections.abc.
• Partialy replace IO in TarFile.

More IO improvements are possible in the future:

• Split into _ReadableFileobj and _WritableFileobj, depending on mode.
• TarFile.bz2open() and .xzopen() still use IO. This depends on improving bz2.pyi and lzma.pyi respectively gaining protocols.
• TarFile.open() and module-level open() still use IO. This could be improved using overloads.
• Some other functions and methods still use IO.

Closes: #5491

[srittau]

GitHub Actions is having issues again. https://www.githubstatus.com/

[srittau]

It passes now.

[JelleZijlstra]

I need more time to look at this properly, but it feels like a shame if we don't switch tarfile.open to a protocol, since that's presumably the main API users would use; it's also the API being used in the linked issue.

[srittau]

Good point about this not closing the linked issue. tarfile.open() (which is alias of tarfile.TarFile.open()) is certainly doable and should be done, but needs may overloads and protocols for lzma and bz2 to be fully typed.

[srittau]

To clarify: If I find time to do more, I'd like to do it in a separate PR. And possibly work on lzma and bz2 first.

[JelleZijlstra]

Looks good apart from one detail

[github-actions]

Diff from mypy_primer, showing the effect of this PR on open source code:

poetry (https://github.com/python-poetry/poetry.git)
- poetry/console/commands/self/update.py:234: error: Argument "fileobj" to "TarFile" has incompatible type "GzipFile"; expected "Optional[IO[bytes]]"