(PUP-2218) Use /etc/yum.conf for yumrepo default location
(maint) refactor find_conf_value to use PhysicalFile
(maint) Update yumrepo inifile provider comments
(maint) expand yumrepo inifile inline documentation.
(PUP-2303) Fix arguments of ArgumentError

Yo dawg, I heard you like ArgumentErrors so I put an
ArgumentError in your ArgumentError.

This makes errors in fileserver config much more readable and
easier to find.
(PUP-1060) Don't fetch latest versions at prefetch

In the previous implementation of yum .prefetch, package providers were
loaded and then the yumhelper.py script was used to determine the latest
versions available for all installed packages. While this worked for
simple cases, trying to support multiple combinations of enablerepo and
disablerepo flags makes this grossly more complex. In addition this
information is not needed at prefetch time, and testing the behavior in
prefetch gets messy.

This commit extracts the latest version query from the prefetch method.
It moves the logic to a method that does the actual querying and lazily
loads that data to keep the same run speeds. When multiple combinations
of enablerepo and disablerepo are added this information can be loaded
in the same fashion.
(PUP-1060) update yumhelper to handle {enable,disable}repo

In order to be able to use enablerepo and disablerepo flags while
ensuring latest, we need to be able to query for packages needing update
with a specific set of repos to enable and disable.

This commit updates yumhelper.py to take two flags '-e' for a repository
to enable, and '-d' for a repository to disable. The values given to
these flags must be a comma separated list of names with no spaces
between them.

It's unsustainable in the long run to continue extending this file, and
we should look very seriously at seeing what behaviors we can remove.
It's impossible to test this as-is and as we add more complexity we risk
introducing more bugs.

Original patch by Matthew Byng-Maddick.
(PUP-1060) Respect yum enable and disable repo flags

When a package resource is ensured => latest, the specific version
available will depend on what yum repositories are enabled and disabled.
Commit a4abf13d3 added the ability to pass arbitrary options to install
and update commands which allowed users to specify the --enablerepo and
--disablerepo options, but these flags would not be respected when the
latest package version was used. This meant that the latest version
found and the version that could be installed with the --enablerepo and
--disablerepo flags might differ, causing all sorts of bad things to
happen.

This commit resolves this issue by making the version query aware of
these flags. When a package checks for the latest version available, it
passes all repositories enabled and disabled to the update query.
Whenever an update query is made for the first time with a combination
of repositories that output is stored, so that only query for a given
combination of repositories is made.

Unfortunately, this change still relies on yumhelper to do the actual
querying. In the long run it would be good to use `yum check-update`
instead of the complex helper script so that we can actually test and
verify the code responsible for querying packages.
(maint) Simplify yumhelper.py output parsing
(PUP-2240) Add unfold of array using splat unary * operator

This adds the ability to unfold values into individual parameters
and entries in lists the same way as this is done in Ruby.
(PUP-2240) Fix failing test (hash order ruby 1.8.7)
(maint) Remove calls to removed function

On master, the extra check if a function was available before evaluating
arguments was removed. The rebased code still had this call.
maint: relax spec test of resources

The resource_spec performs some comparisons by using the equal_attributes_of
matcher. This is mostly correct, but considers some instance variables that are
of no consequence to the resource, e.g. @rstype. As a result, internal changes
to Puppet::Resource that may lead to this attribute not being set in a resource
that is generated from YAML would break this expectation:

expected
Foo::Bar[xyzzy]{:name=>"xyzzy", :one=>"test", :two=>"other"}
to equal attributes of
Foo::Bar[xyzzy]{:name=>"xyzzy", :one=>"test", :two=>"other"}

This is not only difficult to debug, it first and foremost misses the intention
of the example, which is only concerned with RAL attributes, not "internal"
instance variables.
(PUP-1381) issue warnings to current users of cron purging

A behavioral fix is planned for the 4.0 release. The final
3.x point releases should issue early warnings to users who employ
the functionality that is about to change.
(PUP-1381) make file_setting spec test more robust

A new call to self.resource_type in Puppet::Resource#initialize can cause
the loading of type code as a side effect. This interfered with the mocking
for the test

Puppet::Settings::FileSetting when being converted to a resource
should manage existent files even if 'create_files' is not enabled

Add a stubs call to one of the uncritical expectations so that
additional calls are not considered as spurious.
(PUP-2287) Fix lambda param with default is always choosen

This fixes the problem that a lambda parameter with a default always
was choosen even if a value was given for the parameter.

The expected behavior for function calls is that only truly missing (non
given) arguments are subjects to default value replacement, not if a
value is nil or undef. (This because functions are call by position, and
not call by name as for defines and classes). Thus all nil/undef values
are treated as any other value.

One test for the map function relied on the now fixed bug and it has
been marked pending, as it should be updated once the map function has
been transitioned to the new function API. (Where undef is not
transformed to empty string).
(maint) Update test using old style initialization of loaders

The API for creating loaders was changed (now requiring an environment).
This updates the logic that used the old API.
(PUP-2369) Add class to the message we return.

Add the class of the values we're changing from and to in the message
that's being returned. At the very least this will give developers a
hint about the types they're comparing explaining possible weird
behaviour.
(maint) checksum methods should be class methods

Before this change, using a checksum algorithm required creating a class
and including the Checksums module. Since there's no state required for
the checksum methods, this was a silly thing to need to do.

This commit makes the module extend itself, so that the methods can be
invoked by doing `Puppet::Util::Checksums#method`.

In the long run, this module should use the `module_function`
declaration so that the checksum methods are private when included.
(PUP-1840) Add a digest_algorithm Puppet setting, defaulting to md5

Without this patch applied, Puppet only performs checksums of files
using the MD5 algorithm. MD5 is not available on hosts configured for
FIPS 140-2 compliance, so Puppet fails. This patch adds a setting,
settable in puppet.conf, whose name is digest_algorithm and whose
value can be any checksum type known to Puppet::Util::Checksums. The
setting indicates which digest algorithm should be used for performing
checksums. (This patch does not contain the code that pays attention
to the setting.) The value defaults to md5, so that if you do not set
this setting yourself, Puppet will act like it always has before.