(#21817) Ignore duplicate certs

Previously, SSL connections initiated by the puppet agent on windows, e.g
puppet module install, would cause the agent to terminate if the 'Root' store
on Windows contained duplicate certificates.

This commit ensures that we only add unique certificates to the X509 store.
Also, if we fail to add a certificate to the store, we issue a warning and
continue.
(#21241) Add a priority setting

This commit add a `:priority` type of setting that maps generic priority
labels to operating system specific priorities, e.g. normal priority is
0 on posix, but 32 on Windows.

If the value is specified as an integer, then it is passed as is, so
that specific priority levels can be specified.

This commit also adds the `priority` setting to the main section of
puppet's configuration.
(#21241) Set process priority if one is specified

This commit adds a Puppet::Util::Limits module for specifying process
priority, and mixes the module into Puppet::Util::CommandLine. Since
the CommandLine is the application entry point for puppet it seemed
sensible to have it set the process priority there, and to have it done
as early as possible.

Another option would have been to set the priority in the base
Application, after the application-specific settings have been
initialized. But this would mean you couldn't set the process priority
when puppet executes an ExternalSubcommand-based application.

As it stands now, it's not possible to have different priorities for
different sections, e.g. agent vs master, in puppet's configuration
file.
(#22660) Revert Fedora 17+ agent service name to "puppet" from "puppetagent".

Due to pull request 1166, in the fedora 17+ transition to systemd, the puppet
agent service was inadvertantly renamed from "puppet" to "puppetagent".

- in specfile, move systemd service and unit file names back to "puppet" from erroneous "puppetagent"
- Add symlink to puppetagent unit file for compatibility with current bug
- Alter package removal actions to deactivate and stop both service names
- rename unit file in source tree to correspond with this
(maint) Remove shebangs from *.rb files in lib
(maint) Remove executable permission from *.rb files in lib
(#22858) note official ruby 2.0 support in README
(#9546) Make pluginsync copy external facts to client

Pluginsync will now look in moduledir/facts/ for external facts and
copy them to the client under :pluginfactdest (default: $vardir/facts)
(#9546) Use $vardir/external_facts for storing external facts

Puppet loads local ruby facts from "$vardir/lib/facter#{File::PATH_SEPARATOR}$vardir/facts"
so we do not want to store our external facts in this directory.  I
could find no place where $vardir/facts is populated by plugin sync
or any other mechanism so this location must be for facts that do not
belong to a Puppet module and are installed locally on the destination
system.
(#9546) Load external fact directories into facter config
(#9546) Refactoring external fact source and dest to fact.d

The original implementation of this was going to use facts/ as the
source and destination directory.  It turns out the destination
directory facts/ is in use by some outdated code.  So the source and
dest will be switched to facts.d/ which also keeps the naming scheme
consistent with the existing external facts directory
/etc/facter/facts.d
(#9546) Add spec tests for external fact pluginsync
(#9546) Added external fact plugin sync support to plugin face
(#9546) Added feature detection support for external facts

External fact support in puppet core is dependent on facter commit
https://github.com/puppetlabs/facter/commit/6f19eeeef1c5c8e9cc84c44599e03a5c06a30abc
so we need to detect if the installed version of facter is capable
before executing the external fact code
(#9546) Removing PATH_SEPERATOR from pluginfactdest

This is not needed since only one direcrtory will be used for storing
and retrieving pluginsyncd external facts
(#9546) Retrieve module external fact dir from Puppet::Module

Instead of hard coding the external fact directory for modules and
globbing the directories, it would be accurate to have the
Puppet::Module type perform the lookup logic for external fact
directories.   The facts indirector just needs to make sure those
directories get added to the external fact lookup.
(#9546) Update facter specs to support request.environment.modules
(Maint) Clean up code and tests

The way the tests are currently written makes it very hard to get an
overview of all of the behaviors that the code has. This is just the
first step toward getting the tests to be clearer.
(#22918) Lock the filebucket for updates

There were 2 races in the filebucket saving logic:

  1. 2 writers could try to create the `contents` file at the same time.
     This resulted in the writer that loses the race raising an error
     because it did not have write permission to the `contents` file that
     the first writer created.
  2. 2 writers could try updating the `paths` file at the same time.
     This would result in both entering the path in the file thereby
     causing duplicate information in the file. It might also have been
     possible for the two writes to be interleaved in a manner that garbled
     the paths (for instance if the write buffers end up flushing twice in
     an interleaved fashion).

The new method (exclusively_update_file) obtains a LOCK_EX on the
`paths` file before any changes are attempted. This makes the `paths`
file the mutex, not only for updating the paths, but also setting the
contents. This requires that the filesystem supports flock.

Note: the Puppet::Settings.readwritelock method does not work as
intended. It also attempts to get an exclusive lock on a file so that
processes can update it safely, but after testing it out, it actually
does not achieve this. In writing the new method we discovered that the
exclusive lock ability is lost if the update is done using a tempfile
and atomic replace of the file that is locked. When that happens there
is an opportunity for two processes to attain locks and modify the file.
The solution to this was to *only* allow updates-in-place.
(Maint) Introduce File abstraction

Over time we have accumulated various file manipulation operations that
either deal with platform differences of the standard ruby calls or
introduce more useful abstractions for us on top of the ruby calls.
That code has not had a good place to live. Sometimes it appeared on
certain classes, never to be found for use in other areas of the code.
Other times it has been added to the ever growing Puppet::Util mess.

This introduces Puppet::FileSystem::File, which should be used as our
abstraction over ruby's File. We should strive to have it keep a minimal
interface that is geared towards the operations that puppet performs on
files. Inspiration for how to grow it should come, primarily, from uses
found in the puppet codebase as well as from other FS abstraction
systems (such as EFS from eclipse).

This iteration of Puppet::FileSystem::File grew from the file operations
that were done in the filebucket code.