Add native policyfile resolution support

[danielsdeleo]

Auto detects policyfiles and uses them for resolution. It's a bit wonky in that it only works with the chef_zero provisioner, but chef_solo seems to still be the default, so you have to at least add provisioner: chef_zero to your kitchen YAML. I tested with a kitchen YAML like:

provisioner: chef_zero

platforms:
  - name: ubuntu-14.04

suites:
  - name: default
    attributes:
      rando_attr: hello from rando
    named_run_list: foo 

I confirmed the named run list functionality works, and also attributes work as expected, so it will fix chef-boneyard/chef-dk#460

[mwrock]

This is also in chef_base. can we consolidate?

[danielsdeleo]

This logic is also duplicated for the berks and librarian resolvers. If you want I could refactor all of them, but I didn't want to have one pre-refactored and the others not-refactored.

[mwrock]

oh ok. thats fine. we can refactor separately.

[mwrock]

While we are at it, why not move https://github.com/chef/chef-dk/blob/master/lib/kitchen/provisioner/policyfile_zero.rb here?

[danielsdeleo]

A note about the policyfile_zero provisioner: I'd like this to replace that and have that one start emitting deprecation warnings as soon as this patch makes its way into ChefDK. 95% of the policyfile functionality as it relates to kitchen is that of a resolver, and at the moment those are not pluggable, so it's a lot better to have it built-in (auto detection and so on). This will also be easier to use with named_run_list since the data munger is patched to make it work the way users are used to. I guess tl;dr, with this patch there's no reason to use the policyfile_zero provisioner any more and we might as well only maintain one thing that does this.

[mwrock]

Oh got it @danielsdeleo yeah this is WAY better than the provisioner. I'm 👍 here pending we handle the ENOENT scenario above.

[danielsdeleo]

@mwrock done

[adamleff]

This is sweet. 👍