Reconsider high-level API with regards to filters and formats

[brendanhay]

The high-level API in Codec.Archive only exposes a very limited amount of functionality compared to what libarchive itself actually offers. When using the library I've found there's a vacuum between the very nice high-level API and having to re-implement a lot of what already exists internally atop the foreign code in order to access more of the libarchive functionality, such as write filters.

For example, because Codec.Archive.Pack and similar code is hidden - you're limited to the formats that the functions exported from Codec.Archive expose, like packToFile<Format>, etc. If you want to add filters and say, create a .tar.xz or .tar.gz compressed archive - you need to re-implement a non-trivial amount of what already exists in Codec.Archive.Pack just so you can insert the call to archive_write_add_filter_xz. It feels like Codec.Archive.Pack.{filePacker,entriesToFileGeneral} (and similarly for .Unpack) are too useful to remain hidden unless the high-level API comprehensively supports all permutations of filters/formats for writing/reading. I'd rather not have to re-implement the wheel and the overhead of forking, PRing, and so on just to add a new top-level function/export for a certain bespoke combination of filters/formats feels like overkill.

Similarly when reading an archive the filters/formats are set to all - which doesn't give the user an option of configuring only a (potentially safe) subset of those supported.

There's also a related but much smaller issue with creating Entry values from raw FilePaths if you're constructing an archive from a collection of files - having to replicate Codec.Archive.Pack.Common verbatim.

Perhaps if there was an API that lets you have at the ArchivePtr similarly to how Codec.Archive.Pack.entriesToFileGeneral works, as this would allow you to set filters/formats as required without being restricted to what Codec.Archive exports - a sort of midway between Codec.Archive and Codec.Archive.Foreign.* in terms of power to weight. An alternative would be to make more modules available as .Internal.* so we can make use of the existing plumbing a bit more.

[hasufell]

There was some work in #9

[vmchale]

I agree that it's not easy enough to add format support; I think a nice stopgap will be exposing internal modules as you said.

I guess something safer could be done later but as long as performance works out, that will be my first step.