Implement support for pending native crypto

[sempervictus]

@tcaputi has pretty much completed work on native crypto implementation for OpenZFS (openzfs/zfs#4329). This work adds some complexity to how information is stored and presented, as well as CLI interface. Given that the ZenPack works off zdb output, and that dataset-level attributes remain CT, i'm assuming that we should be able to see all relevant attributes whether we have a key loaded or not (aka, should still work while DS is encrypted). We would however want to output information regarding the crypto config (on/off, keysource, cipher, and pbkdfiters) to be logged by Zenoss.

@daviswr: Could i ask you to take a look toward implementation? Every time i start working on this ZenPack i get bogged down by the idiosyncratic differences between Python and my 3rd gen language of choice (Ruby) as relating to string parsing, indents, and set manipulation. I should have some cycles in Jan, but i'm massively behind on Metasploit work, so am throwing this up as an issue instead of a PR presuming you have the cycles to tackle it. Thanks as always.

[daviswr]

Sure, I don't think it'll be too hard if it's zdb and/or zpool-get output, and I should have some time to check it out during the holidays. I'll spin up a VM when I get a chance.

By logged by Zenoss, are you thinking attributes in the details display for pools, events, or both.... ?

[daviswr]

In the mean time, would you be able to send me (sanitized) output from 'zpool get -pH' and 'zdb -L' from one of your crypto-enabled pools?

[daviswr]

Not really tested, but 47f1ddc should let it model the "encryption", "keysource" and "rekeydate" attributes on datasets. They'll say "unsupported" if not found in the zfs get output.

And b241da0 should add "keylocation" and "keyformat" attributes to datasets, and look for "feature@encryption" on pools.

Unsure how to best display any of these, so they're all in respective component details for now.