(#15989) Allow setting arity on functions

The arity value works the same way as for blocks in Ruby.
(#15989) Set arity on functions

Set the arity on builtin functions.
(#15989) Tests for function arity

Test that setting arity on functions work as it should.
(#4695) Puppet should not reset locale for services

Don't reset locale when starting services, we don't parse their output
so there is no need.

This avoids having different locales for services depending on if they
are started on boot or started by puppet.
Removing -e options from pip provider.

-e causes a few problems with puppet:

1. it tries to install to /root/src.
2. It makes the items editable, which isn't useful.
3. reapplying puppet will cause pip to re-install.

Removing -e should help.
(maint) Remove trailing whitespace, retab puppet.init

This removes trailing whitespace from ext/debian/puppet.init and also retabs it
to use 4 space tabs instead of the mix of hard and soft tabs that were present
previously.
(#17447) Stop puppet before returning in debian init script

Without the retry flag, the stop call in the debian init script isn't
guaranteed to stop the puppet agent or master. This commit adds a 2 step
timeout to the init scripts. A TERM signal is sent first, and after 10 seconds
if the process is still running a KILL signal is sent. The unneccessary sleep
call is also removed from the restart case. This affects both agent and
master init scripts.
(#17445) Update logrotate for debian

Previously logrotate would run the postrotate script n times where n was equal
to the number of logs matching the pattern. This could cause puppet to
misbehave if it received several HUP or USR2 signals at once as noted in the
ticket. This commit adds a sharedscripts line to the logrotate rule, which
tells logrotate to only run the postrotate script once, for all matching log
files found.
(#17458) Load 'puppet' at the right time

Previously the Puppet::Util.which method tried to compensate for the
puppet.rb file not being loaded at the right time by trying to load it
itself. When a performance improvement was added (commit 20efe94) to
check if this needed to be done it broke the codepath for executing
external puppet-* commands.

This commit fixes this by requiring 'puppet' at the right place in the
entry point (Puppet::Util::CommandLine) and removing the workaround in
Puppet::Util.which.

Paired-with: Josh Cooper <josh@puppetlabs.com>
Merge branch 'issue/2.7.x/17458-puppet-fall-down-go-boom' of git://github.com/zaphod42/puppet into 2.7.x

* 'issue/2.7.x/17458-puppet-fall-down-go-boom' of git://github.com/zaphod42/puppet:
  (#17458) Load 'puppet' at the right time
Merge branch 'dalen-function_arity'

* dalen-function_arity:
  (#15989) Tests for function arity
  (#15989) Set arity on functions
  (#15989) Allow setting arity on functions
Merge branch 'dalen-service_locales'

* dalen-service_locales:
  (#4695) Puppet should not reset locale for services
(#17361) Re-enable agent forking for catalog run

Commit 6812ee9fc51f327f3a74fc6a6c0eefd9758d0134 introduced agent forking as a
means of controlling the persistent heap size of the Puppet daemon. This
functionality was inadvertently disabled in the conflicting merge commit
23a1a17bebaadbb9b3a1611f34ae46d06b531136.  This is a problem since the agent
fails to utilize this memory-saving code path.

This patch alters Puppet::Agent.initialize to include should_fork as an
additional argument.  Puppet::Application::Agent and Puppet::Run were also
updated to reflect the new method signature.  The agent is instantiated with
should_fork enabled during normal operation.  For --onetime runs and when
instantiated via "puppet kick", should_fork disabled.  In order to preserve the
Puppet::Agent.initialize API for any external users, should_fork has a default
value of true.

Affected unit tests have been updated to reflect the expected forking behavior.
Merge branch 'fix/3.0.x/daemon_forking' into 3.0.x

* fix/3.0.x/daemon_forking:
  (#17361) Re-enable agent forking for catalog run
Merge branch '3.0.x'

* 3.0.x:
  (#17361) Re-enable agent forking for catalog run
(maint) Add expectation pip does not use -e flag

Without this patch we don't have an automated way to validate the
expectation that the pip package provider does not execute with the `-e`
flag present.

This patch makes this expectation explicit and automatically verifiable.
Merge branch 'davedash-patch-1'

* davedash-patch-1:
  (maint) Add expectation pip does not use -e flag
  Removing -e options from pip provider.
Revert "(#17458) Load 'puppet' at the right time"

Commit b5ed15baadffb22b789cebfab7a76e2ab43c7d14 attempted to require
'puppet' at the right time, but failed. The command_line required puppet
before the application was required and its run_mode determined. As a
result, `puppet master` was using the default :user run_mode, causing
its pidfile to be named 'agent.pid' among other things.

This comit reverts b5ed15ba.
(#17458) Partial revert of "don't rebuild regexp every time"

In commit, 20efe94, a change was made to Puppet::Util.absolute_path? to
require the Puppet module only if necessary. This was done as an
optimization since re-requiring a file is much slower than checking if a
constant is defined.

However, defined?(Puppet) is always true when called within the
Puppet::Util.absolute_path? method, so effectively, absolute_path? would
never require the Puppet module, when previously it used to, in certain
exceptional flows.

In the normal flow, it wasn't an issue, because when puppet runs an
internal subcommand (Application), the app requires the Puppet module,
which loads features, which creates an autoloader, which calls the
absolute_path?  method.  At this point, requiring puppet is not needed.

However, if an external subcommand was specified, e.g.  `puppet foo`,
where `puppet-foo` is an external executable, or if no subcommand was
specified, e.g.  `puppet`, the CommandLine would attempt to resolve the
external subcommand using Puppet::Util.which, which calls absolute_path?
at a time when the Puppet module and features haven't been loaded,
causing #17458.

Ideally, the exceptional cases should be requiring puppet rather than
relying on the absolute_path?  method to do so.  However, in 3.x, this
entire logic has been reworked.  In 3.x, the default confdir/vardir
locations are solely based on whether we're running as root or not, and
not the application's run_mode setting.  As a result, we can and do
require puppet early on.

For 2.7.x, the safest thing is to revert the change in the require
'puppet' behavior.
(#17458) Add acceptance test for executing external subcommands

Commit 20efe94 broke running `puppet` and `puppet-*` external
subcommands. This adds an acceptance test to make sure puppet doesn't
blow up when given an unknown external subcommand.

Paired-with: Josh Cooper <josh@puppetlabs.com>