windows_http_acl in a language agnostic way using Windows-API

[maltewitt]

Description

Getting the current URL ACL reservations is now implemented via Windows API (using FFI). The result no longer depends on the language-specific output of netsh.exe

Issues Resolved

#379

Check List

• All tests pass. See https://github.com/chef-cookbooks/community_cookbook_documentation/blob/master/TESTING.MD
• New functionality includes testing.
• New functionality has been documented in the README if applicable
• The CLA has been signed. See https://github.com/chef-cookbooks/community_cookbook_documentation/blob/master/CONTRIBUTING.MD

[chef-supermarket]

Hi. I am an automated pull request bot named Curry. There are commits in this pull request whose authors are not yet authorized to contribute to Chef Software, Inc. projects or are using a non-GitHub verified email address. To become authorized to contribute, you will need to sign the Contributor License Agreement (CLA) as an individual or on behalf of your company. You can read more on Chef's blog.

GitHub Users Who Are Not Authorized To Contribute

The following GitHub users do not appear to have signed a CLA:

• @maltewitt

Please sign the CLA here.

[maltewitt]

The reason for travis-ci failing is the missing httpapi lib, which is part of the Windows-API and only available on windows systems. IMHO this seems to be fine for the windows cookbook.
What is the best way to satisfy travis-ci anyways? Is there some best common practice?

[mwrock]

This is definitely the right direction here. I think you may be able to eliminate alot of the FFI mappings because many already exist in chef core. Have a look at the classes in https://github.com/chef/chef/tree/master/lib/chef/win32/api. Not all is there but probably most.

Regarding travis, typically we just dont run windows native stuff in travis. In this case it would be good to do something like this:

include Windows::UrlAcl if Chef::Platform.windows?

[tas50]

@maltewitt Can you rebase this PR?

[tas50]

Closing this out since we never heard back on the rebase. This is certainly something we'd like to take in. We've done similar conversions to FFI in the past and generally we do the FFI work in a gem, but this is part way towards that end goal.