Add the ability to filter by metric tags

[srfraser]

The original case for this was the ability to filter the disk usage stats by filesystem type, so that duplicate entries for nfs partitions, and meaningless entries like the capacity of /proc weren't submitted.

In order to do this in a way that works for any plugin, a plugin's configuration can now have two subsections: tagpass and tagdrop.

An example configuration section would look like this:

# Read metrics about disk usage by mount point
[disk]
interval = "1m" # Run at a 1 minute interval instead of the default

[disk.tagpass]
fstype = [ "ext4", "xfs" ]
path = [ "/", /opt", "/home" ]

[disk.tagdrop]
path = [ "/" ]

It's important to note that at the moment, the multiple tag filters are OR'd together, so in the example above the 'tag pass' test will succeed if the (filesystem is ext4 or xfs) or (the path is /opt or /home). The tag contents are checked as an exact match. The measurement names are tested as a prefix so that a filter of 'foo' will catch 'foobar', 'foobaz', and so on. This didn't make as much sense with the tags, as you would encounter situations like filtering the root filesystem '/' and accidentally matching all others.

All the measurement pass and drop filters are run first, and so overrule the tag pass and drop filters. All the tag pass filters are checked, then all the tag drop filters are checked. This continues the way that the measurement name pass and drop are working.

Potential points for discussion:

1. I looked at a few ways of encoding this configuration in toml and thought this was the clearest, but I'm open to suggestions for improvements.
2. You could make a case that with multiple tag filters, they should be 'AND' rather than 'OR'. For example, 'if the filesystem type is (ext4 or xfs) AND the path is ( / or /opt or /home )' ...

[sparrc]

This looks good, thank you @srfraser!

re toml: I think this looks fine, carry on :-)

re AND/OR, I'm going to consult with others and see what they think, but I'm leaning towards OR as well

One question about your example: "/" is in both drop and pass, what is up with that? Why would someone want to do that? And since you say that it matches as a prefix, wouldn't putting "/" match everything?

[srfraser]

Having "/" in both drop and pass as an example was mostly because "/" wouldn't make it to the drop tests, if it wasn't in the pass list, just as it does with the measurement names. I think in most cases people will only use one of them. I can swap to multiple separate examples if that's clearer.

Measurement pass/drop matches a prefix, the tag pass/drop has to match exactly, so that "/" doesn't cause unexpected behaviour.

[sparrc]

@srfraser yes, please provide separate examples, or at least make it clear in the example that "/" will pass.

[srfraser]

@sparrc How does README.md look now?

[sparrc]

that's perfect, thanks @srfraser!

I squashed a couple commits and added this to the changelog, so will just close here manually.