fix: Invalid use of subproceess.Popen API with wrapped file objects

[kyujin-cho]

Fix LZMAFile and GZipFile instances incorrectly fed to asyncio.create_subprocess_exec()'s stdin parameter.

The following code looks legitimately working and it actually executes:

with lzma.open(...) as f:
    await asyncio.create_subprocess_exec(..., stdin=f)

Under the hood, the subprocess.Popen constructor calls f.fileno() method that returns the file descriptor representing the raw file stream before decompression.

These confusing behavior made create_subprocess_exec() not to hand out the extracted tarball to the docker load command, but rather passing original uncompressed .xz (or .gz) file, as Popen tries to locate make use of the file descriptor (which returned by fileno() method) rather than using IOBase's high-level read() API where LZMAFile and GZipFile performs decompression.

We should have done either:

with lzma.open(...) as f:
    proc = await asyncio.create_subprocess_exec(..., stdin=asyncio.subprocess.PIPE)
    await proc.communicate(f.read())

(for files whose sizes are controlled by us), or:

with lzma.open(...) as f:
    proc = await asyncio.create_subprocess_exec(..., stdin=asyncio.subprocess.PIPE)
    while True:
        chunk = f.read(CHUNK_SIZE)
        if not chunk:
            break
        proc.stdin.write(chunk)
        await proc.stdin.drain()
    await proc.communicate()

(for files that may have arbitrarily large sizes).

Even though it is definitely not an intended situation, as docker load also accepts tarballs compressed with either XZ or GZip algorithm (ref) - which has effectively hidden this long-standing bug, at least for more than 5 years...

Checklist: (if applicable)

• Milestone metadata specifying the target backport version