Decouples Filesystem implementation

[dgmcdona]

This refactors the way that the parser handles paths in general, removing the filesystem-specific implementation details from the parsing fuctions, and providing a new interface centered around providing the correct readers through the FileProvider trait. Default implementations for live-system and logarchive formats are provided, as are utilities for categorizing files by path. This requird updates throughout the repo's tests, and if merged, will require updates to the larger tests that are currently shipping in the test archive.

[dgmcdona]

@puffyCid The tests included in the crate are passing - paths.rs needs more tests but it's late and I figured I'd go ahead and put this forward for some initial review.

There are a couple of things that I'm not sure about right now:

1. Should the FileProvider trait yield Result items instead of just Box<dyn Read>? Or should error handling when producing readers be left to whoever implements the trait?
2. Should the trait's iterators also yield path information in addition to the readers? This lead to some changes when updating the examples, since access to the source file names is lost.

[puffyCid]

@dgmcdona This is looking good. Few thought so far:

1. Result vs Box. Either one seem fine to me. I am incline to say let the users determine how they want handle trait error handling
2. Lets try to include path info in the reader. I think that may be useful to keep

For tests, I uploaded test_data.zip to the releases page. I will open PR that will commit the tests/*.rs files and update CI to only pull down the test_data.zip that should then make it possible i think to make changes to those files in this PR

[dgmcdona]

Increased two check values in separate tests - more records were being returned, presumably because of the inclusion of the Signpost directory.

[puffyCid]

This is looking really good, im really happy the tests all pass.

I tried out the example files, looks like some minor issues may slipped through.
Could you make sure the examples still run?

1. I left some comments for unifiedlog_iterator
2. parse_tracev3 works fine
3. Both unifiedlog_parser and unifiedlog_parser_json print errors below:

./unifiedlog_parser_json -l -o out4.csv
Starting Unified Log parser...
error: a value is required for '--input <INPUT>' but none was supplied

./unifiedlog_parser_json -i ~/Downloads/system_logs.logarchive -o out4.csv
Starting Unified Log parser...
thread 'main' panicked at unifiedlog_parser_json/src/main.rs:147:10:
called `Result::unwrap()` on an `Err` value: Os { code: 20, kind: NotADirectory, message: "Not a directory" }
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

[puffyCid]

@dgmcdona if u have time and get chance to at least fixup the unifiedlog_iterator example. I would be happy to merge.
Otherwise, i guess merge now and fix the examples in subsequent PR

[dgmcdona]

Thanks, I'll push the remaining fixes shortly

[dgmcdona]

There was so much functionality shared between the examples that I just bundled it all together with a --mode flag in unifiedlog_iterator, renamed it to unifiedlog_parser, and removed the others. Fixed the bug with read -> read_to_end, as well as the warning being emitted because the dsc directory itself wasn't being filtered from the LiveSystemProvider's dsc file paths.

[puffyCid]

looks good thanks!