Initial version of an mtree module

[kevans]

note: I'll split the few housekeeping bits out pre-commit, I decided they weren't major enough to worry about creating separate views for. Still needs documentation, but I wanted to get an early version up.

[emaste]

See also tools/pkgbase/metalog_reader.lua - will take a look at migrating to using this module instead later on

[kevans]

In D50833#1160246, @emaste wrote:

See also tools/pkgbase/metalog_reader.lua - will take a look at migrating to using this module instead later on

Hmm, I had missed that; I'll take a look and see if there's any inspiration I can draw back into this module.

[kevans]

"kevans provided some initial review" -- ouch, I should have remembered that... OTOH, this one aims to be completely mtree(5) compliant and allow mutation from lua, which is a bit broader in scope than metalog_reader.

The main feature implied as necessary by metalog_reader is better linting: pkgbase wants to know about duplicate entries, which we'll just silently dedupe and the consumer of mtree(3lua) wouldn't be able to detect that. Everything else seems mostly doable, though we'll also want to provide some kind of iterator over the tree so that it can do most of the remaining filtering/metrics. Perhaps also a mechanism to just get a dirent's path relative to the root (rather than the mtree-style path) would be useful.

Thinking a bit more about the linting, I suspect the easiest/best option for everyone is I just add an optional callback when a duplicate entry is encountered that we invoke with the existing dirent and any keywords associated with the new entry. metalog_reader would supply that and decide if the duplicate is significant.

[kevans]

Improve parsing, fix chdir() behavior for absolute paths and non-directories

Absolute paths and non-directories aren't supposed to cause us to chdir. The
former only surfaces as a problem if you try to mix both absolute and
non-absolute in one mtree, so it's usually not a problem.

Added a few more examples, but still not documentation quite yet

Added a handle_dupe option to the parser; when we encounter a duplicate, we'll
pass back the existing entry, the keywords from the new entry, and the line
number that it was encountered on for the caller to act on. The caller can
just agree to merge the entry, discard it, or return an error. Note that
discarding it doesn't prevent the handle_dupe() callback from deciding to merge
in some subset of the properties if it wants to and asking the parser to drop
the rest -- the subsequent chdir() would still happen to avoid misprocessing the
mtree.