(maint) Remove warning added during debugging
PUP-1450 Windows file resource Invalid DACL errors

 - When the source of a file resource is referred to through a symlink
   it's possible the volume for the real file does not support ACLs.
   Unfortunately it's not possible to simply readlink the path to
   determine the real path / volume, so the best thing to do is
   attempt to read the DACL of the file, catch the exception when it's
   invalid and fallback to default owner / group / mode on Windows.
 - Furthermore, under VirtualBox, the standard ERROR_INVALID_DACL is
   not the error that propagates, but rather ERROR_INVALID_FUNCTION, so
   there is special handling for that scenario.
 - Note that this particular issue also affects paths like the Puppet
   module path puppet:///modules that may be symlinked in environments
   like Vagrant.
PUP-1450 Honor source_permissions_ignore

 - In further debugging this failure, it was discovered that despite
   the :source_permissions parameter being set to :ignore on the file
   resource type, that we're still attempting to stat the source file
   and extract group / owner / mode.  So instead of trying to stat the
   file, catching errors, and falling back to defaults, we properly
   ignore the group / owner / mode of the source file and provide
   reasonable defaults on both Windows and Linux.
 - In Windows, the defaults continue to be
   :owner => 'S-1-5-32-544' (BuiltinAdministrators)
   :group => 'S-1-0-0' (Nobody)
   :mode => 0644
 - On other operating systems, the defaults are now set to be
   :owner => Process.euid
   :group => Process.egid
   :mode => 0644
 - Several tests were refactored to be less fragile with respect to the
   :source_permissions parameter
(PUP-1549) Use standard reason phrases on webrick

The webrick interface was using the body of the response for the reason
phrase for non-2xx responses. In the v1 api, this meant that we got
bizarre response headers. In the v2 api, it meant that we got json
formatted body data in the first header.

Not only was that state of affairs odd, it was also inconsistent with
the rack implementation, which didn't ever set the reason phrase. I am
also a little concerned that some clients might have choked on large
reason phrases (header too long issues).

This removes the setting of the reason phrase on webrick, which give us
back the standard reason phrases.
(PUP-1549) Update documentation showing reason phrase

All of the error responses that we had used as examples in the API
documentation had been taken from using webrick. Now that webrick is
consistent with rack, the docs need to be updated to show what the
responses should really look like.
Merge pull request #2315 from zaphod42/issue/master/pup-1549-v2-funky-response-phrase

(PUP-1549) Use standard reason phrases on webrick
(maint) Acceptance install_utils uses release rpm symlinks

The Puppet::Acceptance::InstallUtils was fiddling with extraneous
parsing trying to pick the current release rpm version from deep in
hierarchy of yum.puppetlabs.com.  Now we make use of the root symlinks.
(PUP-576) Update store_configs test for Debian

The store_configs/enc_provides_node_when_storeconfigs_enabled.rb test
has been updated to use Activerecord 3.2.x, but this version of
Activerecord no longer supports the sqlite3-ruby gem package available
on Debian via apt.  So we are installing the newer sqlite3 gem.  As an
added wrinkle, this is the same name as the core sqlite3 package on
Debian, running us afoul of PUP-1073 (duplicate names for packages
handled by different providers).  We are working around that with a
separate puppet apply for the sqlite3 installation.
Merge branch 'issue/master/pup-576-fixup-store_configs-test-for-debian'

* issue/master/pup-576-fixup-store_configs-test-for-debian:
  (PUP-576) Update store_configs test for Debian
  (maint) Acceptance install_utils uses release rpm symlinks
Merge branch 'master' of https://github.com/puppetlabs/puppet