Add tar/asm.IterateHeaders

[mtrmac]

This allows reading the metadata contained in tar-split without expensively recreating the whole tar stream including full contents.

We have two use cases for this:

• In a situation where tar-split is distributed along with a separate metadata stream, ensuring that the two are exactly consistent
• Reading the tar headers allows making a ~cheap check of consistency of on-disk layers, just checking that the files exist in expected sizes, without reading the full contents.

This can be implemented outside of this repo, but it's not ideal:

• The function necessarily hard-codes some assumptions about how tar-split determines the boundaries of SegmentType/FileType entries (or, indeed, whether it uses FileType entries at all). That's best maintained directly beside the code that creates this.
• The ExpectedPadding() value is not currently exported, so the consumer would have to heuristically guess where the padding ends.

Cc: @kwilczynski

[kwilczynski]

@mtrmac, this is very nice! Thank you for exposing this!

There was a use case I had where exposing FileType and Payload (so the CRC64) would be useful. But I don't know if this is something we would like to do and what the complexity of this would be.

[kwilczynski]

/approve
/lgtm

[vbatts]

Interesting use-case. Thanks for that.

[vbatts]

and i've tagged release v0.11.6

[mtrmac]

@vbatts Thanks!

[mtrmac]

There was a use case I had where exposing FileType and Payload (so the CRC64) would be useful. But I don't know if this is something we would like to do and what the complexity of this would be.

The current code simply ignores FileType, but it already assumes that there is only one tar header per SegmentType; so changing that to expect the two to interleave regularly, and to collect the other data, seems easy enough to do.