RFE: Abstract out file system operations

[imp]

It may be beneficial for testing and/or other purposes to allow consumers of this crate to choose the underlying file system implementation. Right now tar calls std::fs functions directly, which leaves no chance for any other implementation to plug itself in. I'd imagine that internally the implementation might use a [replaceable] object that will drive the fs-related activity. Naturally, by default, it should behave the same as today, but if someone will need to substitute it with something different it will be just a matter of passing an appropriate object during the initialization.

For example, filesystem crate provides API like that as well as allows to extend it with even more creative implementation.

So if I would need to unpack the tar archive in, say, a memory-based virtual filesystem (unit tests, or similar) I will just create Archive with the relevant handle and then just call the usual functions, like Archive::unpack. The alternative is to carefully re-implement the complex logic in unpack again and again, which is not so good.

[rbtcollins]

We have a concrete use case for this now in rustup - rust-lang/rustup#1867 - specifically we need to shift all the open operations to threads; I was thinking that having an overlay filesystem that tar-rs could write to, but that would then flush safely in order to disk, would provide a pretty clean way of doing this. So tar-rs would run single-threaded through the tar (which being linear is a natural thing), the virtual FS would buffer up operations and flush them in as many parallel threads as the structure permits; would answer realpath/link calls and the like based on the calculated status, and thus cope with tars that link to newly extracted files and the like. I'm happy to put together the work for this, but would like some nod from @alexcrichton about whether this is a reasonable direction or not.

[rbtcollins]

@imp as I note #207 (comment) Entry implements Read (I finally read the README.md :P). So, you can unpack in memory just fine, just without the Entry::unpack function.

I think its a worthwhile question whether the unpack() function should even exist on Entry: should it perhaps just be a helper iterator or something appropriately parameterised with types, but Entry implementing Read changes my whole approach on tackling this :).

[alexcrichton]

I think this is something I would prefer to not add and maintain in this crate. I want to make sure that you can do this externally if necessary, but I believe you already can with all the existing APIs.

There's probably better things we can do to ensure it's easier to reuse the unpacking logic on Entry, but I am going to close this because I'd prefer to not add something liek a Filesystem trait to work with.