add in a package os version compatibility check

[dsbaha]

What type of PR is this?

Uncomment only one /kind <> line, hit enter to put that in a new line, and remove leading whitespace from that line:

/kind api-change
/kind bug
/kind cleanup
/kind deprecation
/kind design
/kind documentation
/kind failing-test

/kind feature

/kind flake

What this PR does / why we need it:
This adds in a os version compatibly check on cpe_remote_file. Some PKG files have strict os version requirements defined in the Distribution file. This check evaluates if the pkg is compatible for the OS its being installed.
Which issue(s) this PR fixes:

Fixes #

Special notes for your reviewer:

Does this PR introduce a user-facing change?:

Additional documentation e.g., Design Proposals, usage docs, etc.:

[facebook-github-bot]

Hi @dsbaha!

Thank you for your pull request and welcome to our community. We require contributors to sign our Contributor License Agreement, and we don't seem to have you on file.

In order for us to review and merge your code, please sign at https://code.facebook.com/cla. If you are contributing on behalf of someone else (eg your employer), the individual CLA may not be sufficient and your employer may need to sign the corporate CLA.

If you have received this in error or have any questions, please contact us at cla@fb.com. Thanks!

[facebook-github-bot]

Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Facebook open source project. Thanks!

[gbatye]

So the goal is to skip package installations if /usr/sbin/installer -volinfo does not contain "MountPoint"?

Do you have an example output for a package that does not contain "MountPoint"?

Also I believe that this resource will fail if a package is not compatible with the OS and that will inform user to gate the package to particular OS versions.

[erikng]

All packages will have a mount point as it's a standard attribute.

For context, what we are trying to solve is when users are running beta OS versions, some packages may fail. You are correct that chef will fail and this is behavior we do not want to occur.

We would rather this package not install and we don't want to have to continuously baby our fleet.