source function library *before* client sysconfig overrides

My client's environment mandates strict umask settings:
  - 027 for init scripts
  - 077 for normal users
This causes problems when using exec resources or any add-on functions
that exec external scripts/programs.

The fix is relatively simple - run umask in /etc/sysconfig/puppet
and set a more lenient umask for puppet.
However, the /etc/sysconfig/puppet is sourced before the init
function library so any umask changes made in the former are
overridden by any in the latter.

Looking in other init scripts (including the puppetmaster init
script), it is usual for the function library to be sourced at the
start of the init script, ie. before the sysconfig override.

This change simply moves the lines that source the init function
library to the start of the init script.
(maint) Simplify the CA use of the autosign setting

Commit bca628dc adds proper conversion of autosign input values to
booleans, but Puppet::SSL::CertificateAuthority was still trying to
handle string values. This commit simplifies the checking logic and lets
the autosign setting handle data normalization.
(PUP-1174) enable the purging of authorized ssh keys

Purging authorized ssh keys is difficult because there is no way know
where key files may be located. Users commented that for most it should
be sufficient to clean the keys from users that puppet manages.
John Bollinger suggested a design that's based on a new parameter to the
user type. There are two ways to use it:

user { "name": purge_ssh_keys => true }

to make puppet purge from the default ~/.ssh/authorized_keys file, or

user { "name": purge_ssh_keys => [ "/etc/keyfiles/name" ] }

to specify one or more files in non-standard locations.

The implementation is similar to the file type's purging code. The user
type now has an eval_trace method that searches the specified files for keys
and adds any unmanaged keys to the catalog with ensure => absent.
(PUP-1174) amend resources type documentation

Add a reference to the new purging feature to the documentation of the
resources type description.
(PUP-1174) add tests for the purge_ssh_keys parameter of the user type
Clarified `pattern` parameter for Service type (DOCUMENT-1)
(DOCUMENT-22) Clarify matching of crontab entries

This updates the documentation to be consistent with behavior introduced in
commit da9162c.
(maint) Add optional_parameter_count method to Closure

Add a method to return number of optional parameters on
Puppet::Pops::Evaluator::Closure just like Puppet::Parser::AST::Lambda
has.
Clarified the use of slashes around RegEx for `pattern` attribute
(pup-1524) Correct resource_present? to account for purged

The fix for http://projects.puppetlabs.com/issues/23081 included
e376b9d8, which refactored some of the resource_harness code and
introduced ResourceApplicationContext.resource_present?

At the time that method only checked current_values[:ensure] against
:absent, which meant that if current_values[:ensure] was :purged,
then resource_present? was true and the code thus attempted to
sync additional properties. This resulted in the double events
noted in this ticket (the first one in manage_via_ensure_if_possible,
the second (unnecessary) one in sync_if_needed).

This change adds a present? method to Puppet::Type, the default
implementation of which just checks for :ensure != :absent, but
which must be overridden by other types that have additional values
for :ensure that also imply that the resource is not present. It also
overrides that method in the package, file, and interface types,
each of which offer such additional values for :ensure.

In addition, there was another code path for duplicate events
because the previous code didn't distinguish between not using
ensure and the ensure check failing (e.g. due to a provider failure).
To address this, the code was refactored slightly to introduce
the NO_ACTION return from sync_if_needed.
Fix PUP-1568 - no success variable anymore

In the refactoring within 000b8fef the success variables was
removed. So the error message shouldn't anymore use it.
Fix broken spec & wording of error message.

While working on 658f1237c1596a6f735b7b707130fc0897a1a113 I stumbled
accross another messages that would say 'with error code false', which
doesn't make a lot of sense. Also the plain 'expect raise_error' was
masking another problem with tests. One should always only look for the
exact expected error and not just general for any kind of error.
(PUP-1066) Add the ability to delete files.
Add a .destory and .destroy? in order to flag files for deletion.
We also sneak in a .entries reader in order to let us read the
entries directly.

This should fix PUP-1066 and #12687.
Merge pull request #2321 from kylog/issue/stable/pup-1524/duplicate-events-for-some-providers

(pup-1524) Correct resource_present? to account for purged
(Maint) Extract re-usable resource matcher

Checking that catalogs have particular resources is useful. Let's make
it easier. This also adds parameter matching to the resource matcher.
(maint) Add how-to for destroying individual hosts
(PUP-865) Allow BlockExpression to evaluate everything

Previously BlockExpression would skip evaluating any AST nodes that
implement an instantiate method. The assumption was that instiate only
existed on Hostclass, Node, and Definition AST nodes and those same
classes also did not implement an evaluate method. With the introduction
of the PopsBridge::Program class, this entire house of assumption cards
came falling down, since it impelements both instantiate and evaluate.

The only thing that truly prevented BlockExpression from calling
evaluate was that the default evaluate implementation on Parser::AST
raised a Puppet::DevError to try to catch the case of evaluate not
being implemented for an AST class. Since Parser::AST is entirely
internal and missing an evaluate should show up very quickly in tests,
we can just as easily make evaluate a noop by default, which then
simplifies BlockExpression.

This change fixes the problem where the body of pp files were loaded,
but not evaluated when using the future evaluator and a directory of
manifest files. The problem was triggered by the BlockExpression logic
interacting with the PopsBridge::Program object and the structure
created by the Puppet::Pops::Parser::CodeMerger.
(PUP-865) Only use the pops merge for the future evaluator

The future evaluator is only really in play when both the parser is
future and the evaluator is future. The old check left out the evaluator
portion of that check and so ended up using the wrong CodeMerger when
using the current evaluator with the future parser.
(Maint) Clean up tests
Merge pull request #2325 from zaphod42/issue/master/incorrect-loading-from-manifest-directories

(PUP-865) Fix loading from directories in the future evaluator