(#6371) Update lastchg field when updating password

On Solaris the password= method updates the `/etc/shadow` file directly
to set the new password but it does not update the `lastchg` field to
the current day. This way a password can expire even though it was
updated with puppet.

The fix was first supplied in commit 6ef1d3a but was later removed after
a refactor in 7900a66.
(#20742) Only use certifcate info if there is a CN

Because of the changes to puppet/util/ssl for this issue, the DN
was now always able to be parsed into something. This uncovered that the
logic around deciding on the node name and authentication status for the
request was incorrectly based off of simply the existance of a DN in the
headers. This caused a DN that was missing a CN to have an unknown node
for a request, which could be marked as authenticated if the verify
header was "SUCCESS".

This patch fixes it by basing the decision of using the SSL headers on
the existance of the CN instead of the DN. Now a CN must be present
(e.g. a valid DN) for the verify header to be used. When no CN is
present, then it is treated the same as no DN being present, which
causes a reverse DNS lookup to be done for the node name.
Merge branch 'stschulte-ticket/stable/6371_reset_lastchg_on_solaris'

* stschulte-ticket/stable/6371_reset_lastchg_on_solaris:
  (#6371) Update lastchg field when updating password
Merge pull request #1652 from adrienthebo/maint-static_compiler_yardoc

(static compiler) Add method documentation
Adding a couple additional tests for supplied version constraints.
Certain server configurations are less diligent about whitespace.

This is primarily a fix for our acceptance testing environment.
(#17871) fix nagios types uniqness under ruby 1.9

In ruby 1.8 and earlier, splatting a 1-element array would return the first
element, post 1.9 you always get an array back.

    $ ruby-1.8.7-p371 -e 'a = ["a"]; b = *a; puts b.inspect'
    "a"

    $ ruby-1.9.3-p429 -e 'a = ["a"]; b = *a; puts b.inspect'
    ["a"]

This lead to an issue in the nagios providers where the parameters['name']
would be set to an Array, so simple 'does this resource already exist
checks' would fail as  `parameters['name'] == some_string` would always be false.

This patch changes the assignment from a splatted array to an explicit call to
args.first, which is portable between 1.8 and 1.9 and restores the intended
behaviour.
Merge remote-tracking branch 'zaphod42/issue/stable/20742-no-handling-of-bad-dn-in-rack' into stable

* zaphod42/issue/stable/20742-no-handling-of-bad-dn-in-rack:
  (#20742) Only use certifcate info if there is a CN
  (#20742) Handle DNs that cannot be parsed
  (Maint) Give each test a meaningful name
Merge branch 'stable'

* stable:
  (#20742) Only use certifcate info if there is a CN
  (#20742) Handle DNs that cannot be parsed
  (Maint) Give each test a meaningful name
  (#20726) Manage home has issues on Solaris
  (#20726) Include password for useradd managehome tests on windows
  Revert "Merge branch 'pull-1512'"
  (#20726) Add user managehome acceptance tests
  (packaging) Update PUPPETVERSION to 3.2.0
(maint) Change load order for puppet/provider/package/windows/package

Uncovered a load order issue with
puppet/provider/package/windows/package being loaded before
puppet/type/package.  This was manifesting in various test runs as
'uninitialized constant Puppet::Util::Windows::MsiPackage' or
'uninitialized constant Puppet::Util::Windows::Package' (or similar case
where Puppet::Provider::Package::Windows somehow ends up pointing to
Puppet:Util::Windows).

This patch just require's 'puppet/type/package' at the beginning of
puppet/provider/package/windows/package.  Which fixes the immediate load
order issues seen in the specs, but is not a long term fix.

More investigation is needed to pinpoint what's going on.
Merge pull request #1655 from jpartlow/maint/puppet-provider-package-windows-package-load-order-issue

(maint) Change load order for puppet/provider/package/windows/package
Merge branch 'stable'

* stable:
  (maint) Change load order for puppet/provider/package/windows/package
(packaging) Update PUPPETVERSION to 3.2.1-rc1
Merge branch 'stable'
(maint) Reset confines on the pip provider after tests

The tests for pip alter the confines for the pip provider by stubbing the
underlying facter calls and then calling lazy_pip. This can leak into later
tests, causing weird failures.
Merge pull request #1654 from pvande/tickets/master/17824-pmt-should-not-prefer-prereleases

(#17824) PMT should not prefer pre-release versions over existing stable versions
(maint) More specific require for windows/package

PR1655 added "require 'puppet/type/package'" to fix a load order issue.
But this change is more general than what is needed, and we had not
tracked down exactly what was occurring.

I spent a little time running down the load order issue for
puppet/provider/package/windows/package.  An example of the mystery
effect being that prior to PR#1655 the following sequence would pass:

bundle exec rspec spec/unit/provider/package/rpm_spec.rb
spec/unit/provider/package/windows/package_spec.rb

while the reverse order would fail:

bundle exec rspec spec/unit/provider/package/windows/package_spec.rb
spec/unit/provider/package/rpm_spec.rb

The reason for it is confusing, but turns out to be not very mysterious
or magical at least.

The summary is that because this was written as follows:

lib/puppet/provider/package/windows/package.rb
---
1  require 'puppet/util/windows'
2  
3  class Puppet::Provider::Package::Windows

Puppet::Provider::Package is assumed, but not required.  Since
Puppet::Provider is loaded as a result of the base require 'puppet', and
since it includes Puppet::Util, which has a Puppet::Util::Package, if
nothing else has explicitly created Puppet::Provider::Package, we
end up declaring the Windows class on Puppet::Util::Package and hiding
reference errors which should otherwise pop up here.

Requiring 'puppet/type/package' does end up also requiring
'puppet/provider/package' as part of type's autoloading magic, but this
patch more specifically and clearly fixes the issue by requiring
'puppet/provider/package'.

Consistency of namespacing and class loading is a deeper issue.
Merge pull request #1656 from jpartlow/maint/windows-package-load-order-cleanup

(maint) More specific require for windows/package
Merge pull request #1643 from jeffweiss/20442_fix_aix_extended_attributes

(#20442)[PE-161] fix AIX extended attributes
Merge pull request #1649 from richardc/fix/master/17871

(#17871) fix nagios types uniqness under ruby 1.9