Magic module

[Blacksyke]

Port of the magic module. Note that building this feature requires libmagic in your Rust library path.

I've implemented both magic.type() and magic.mime_type(), no rule changes should be needed. After chatting with @wxsBSD, we decided it was best to add a minimal protobuf specification rather than hack the build scripts to account for modules that only have exported functions and return no data, like this one.

Right now, I'm mostly asking for feedback. A notable omission from this implementation is the cache design present in the C version. I imagine adding this would still be a net performance gain, but I want to make sure this design seems reasonable first.

cargo test --package yara-x --lib --features magic-module -- modules::tests::magic::e2e_test --exact --nocapture

   Compiling yara-x v0.1.0 (yara-x/yara-x)
    Finished test [unoptimized + debuginfo] target(s) in 1.76s
     Running unittests src/lib.rs (target/debug/deps/yara_x-56a7c9914ffab9dd)

running 1 test
test modules::tests::magic::e2e_test ... ok

test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 24 filtered out; finished in 0.14s

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[plusvic]

This looks good to me. The cache system is important but I'm not sure how to implement, maybe we need to provide a mechanism so that modules can store arbitrary data in the ScanContext and retrieve it later. Also, run rustfmt with the rustfmt.toml file in the root directory.

[Blacksyke]

RFD

Having been stymied in my previous testing file layout by module scope problems, I have resolved to move this module into a directory with tests alongside, as we do with the scanner component. This is probably slightly better overall, as larger modules spanning multiple files will want their own directory anyway. What do we think? I still hate having to specify the fact that that there are tests in the module file itself, but I can't find anything more elegant that actually works right now.

If we're OK with requiring tests for modules, we could probably enforce this when writing modules.rs, i.e. having the build script break if it doesn't find <module>_tests.

The caching system remains #todo at this time.

cargo test --package yara-x --lib --features magic-module -- modules::magic::tests --nocapture

running 3 tests
test modules::magic::tests::get_filetype ... ok
test modules::magic::tests::get_mimetype ... ok
test modules::magic::tests::e2e_test ... ok

test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 32 filtered out; finished in 0.12s

[plusvic]

I think that having the module's test within the module's itself is ok, as this is a well-known Rust pattern. For small modules having a single file is also ok, while larger ones can have its own directory, like in this case.

[plusvic]

Already merged in #91.