tar/asm: add NewInputTarStreamWithDone + tests

[jankaluza]

Refactor tar disassembly into a shared runInputTarStream goroutine and newInputTarStreamCommon setup helper.

Introduce bestEffortPipeWriter to allow tar parsing and metadata packing to complete even if the consumer closes the pipe early.

Add NewInputTarStreamWithDone, which returns an io.ReadCloser together with a done channel that is signaled when the internal goroutine finishes (or fails), including the final padding-draining phase.

Preserve existing NewInputTarStream behavior and API.

Add unit tests covering:

• successful full reads
• early consumer close
• packer error propagation
• underlying reader failure while the tar-split goroutine is still running

This is needed to fix containers/container-libs#148. Please check this ticket for more context.

[jankaluza]

@mtrmac , can you please check this when you have time? :-)

[mtrmac]

A fairly quick look. I didn’t read the tests at all yet.

Is there a corresponding consumer PR to prove the concept and demonstrate how the API is used?

---

Nothing in the commit / comments says why we need it, and I think it’s important to preserve that knowledge. (The PR description does link to a part of the motivation, but that’s not going to be obvious to people just reading the code.)

• Whether processing the tar stream succeeds, fails inside tar-split, or fails in the consumer of tar-split, we need an ability to block until the goroutine terminates (and the input r reader is safe to deallocate / reuse). I think the done channel works fine for that.

• If processing the tar stream fails in the consumer of tar-split, and that consumer aborts, the consumer does not want to read all of the tar to completion. In that case, the current code’s goroutine will just hang trying to write to an abandoned pipe, and keep memory allocated forever.

  • Returning a ReadCloser and having the Close signal an abort works (unlike using a Context, which can’t abort a pipe write).
  • I wonder about directly returning a PipeReader. That might allow the consumer to use CloseWithError and potentially allow better diagnostics, OTOH the goroutine is not currently logging anything anyway — and returning a PipeReader would be more of an API commitment. I don’t have a strong opinion.
  • In both of the callers in c/storage, if consuming the tar from this function fails, nothing uses the data produced by storage.Packer. So I don’t think the bestEffortPipeWriter is necessary — it’s actually unwanted for us, because the goroutine will continue consuming the input and burning I/O or CPU (and blocking the caller who just wants a done signal and terminate), for no benefit. It would be better if the goroutine saw the pipe write fail, and terminated.

[jankaluza]

@mtrmac , example of this code in use is here: https://github.com/containers/podman/pull/28018/changes#diff-1169f6e33aa043d846707f96a461aedef54252acc9290f5e5e2c64cce0c2920f