(#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
Maint: Clarify that the managehome parameter will delete a home directory

Users have sometimes been surprised that managehome will delete a home
directory when removing a user. This commit makes that explicit.
Merge pull request #1265 from nfagerlund/clarify_managehome

Maint: Clarify that the managehome parameter will delete a home director...
(maint) Fix hiera_include spec tests

Without this patch applied, the hiera_include function spec tests are
not examples of actual behavior.  In the spec tests the stubbed methods
would return an empty array, which would then be forwarded straight away
to the include parser function.  The example did not have the
expectation that this would raise an error.

This behavior is a problem because adding arity checking to the
functions becomes more difficult if theses examples are not
demonstrating exepcted behavior.  Instead, the change to check arity
causes these examples to fail unexpectedly.

This patch fixes the problem by setting the expectations of the actual
behavior of the hiera_include functions more accurately.  An empty array
is no longer returned from the stubbed Hiera behaviors.  This patch
causes us to expect the system to take exception with trying to include
a non-existent class.
Merge branch 'maint/3.0.x/fix_hiera_include_specs' into 3.0.x

* maint/3.0.x/fix_hiera_include_specs:
  (maint) Fix hiera_include spec tests
(#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
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>
Merge pull request #1271 from joshcooper/ticket/2.7.x/17458-undo-performance-fix

(#17458) Undo minor performance change in 2.7.x
Merge remote-tracking branch 'upstream/2.7.x' into 3.0.x

* upstream/2.7.x:
  (#17458) Add acceptance test for executing external subcommands
  (#17458) Partial revert of "don't rebuild regexp every time"
  Revert "(#17458) Load 'puppet' at the right time"
  (#17458) Load 'puppet' at the right time
(#17458) Re-enable performance fix

Previously, commit 20efe94 tried to only require puppet if it wasn't
loaded. However, defined?(Puppet) was always true when called by
absolute_path?, so the require was never executed.

Commit 327aff5, changed it to always require puppet, due to the way
puppet is required in 2.7.x. However, in 3.0.x, puppet is required at
the very beginning of command_line.rb (which is why 3.0.x didn't have
the same problem as 2.7.x).

This commit restores the behavior in 3.0.x, of never requiring puppet
from the absolute_path? method. I didn't want to make this change in the
merge commit, so it's clear why the logic is different.
Update lib/puppet/version.rb for 2.7.20-rc1
Merge branch '2.7.x' into 3.0.x

Conflicts:
	lib/puppet/version.rb
Merge pull request #1260 from haus/ticket/3.0.x/17447_fixup_init_script

Ticket/3.0.x/17447 fixup init script
[12833] Refactor directoryservice user provider

Previously, the OS X directoryservice user provider could not handle
10.8 users due to version 10.8 of OS X implementing PBKDF2-style
password hashing/stretching. The user provider also struggled with
setting 10.7-style passwords in a single run due to the way that
passwords are stored in OS X versions 10.7 and higher.

The `dscl` binary is in charge of changing user attributes, and CAN be
used to set a user's password, but it must be provided with a plaintext
password. We have discovered no way to use `dscl` or `dsimport` and pass
it a password hash that will be set for a user. Because of this fault,
the user's plist located in /var/db/dslocal/nodes/Default/users must be
directly modified. Because the `dscl` command maintains its own caching
system, changes made using the dscl command will not be immediately written
to disk. Conversely, DIRECT CHANGES to the user's plist file will NOT be
recognized by the dscl command unless you flush its cache. Flushing the
dscl cache is an asynchronous action, however, so you must sleep long
enough for dscl to read-from/write-to disk.

With the mechanism for reading/writing passwords cleaned up, the problem
remains that 10.8 uses PBKDF2 passwords that rely on a `salt` and `iterations`
value. These three values (the hash, the salt, and the iterations value)
together form a unique key that comprise the user's password. Because
the salt and iterations values must be specified, the user type had to
be modified to allow these values to be passed in a user resource
declaration. This change does not break clients on versions of OS X
older than 10.8.

With these two faults in mind, the decision was made to completely
re-write the directoryservice user provide so that it shed its reliance
on the lib/puppet/provider/nameservice/directoryservice plugin and was
completely independent. This commit refactors the directoryservice user
provider according to the aforementioned deficiencies and implements
tests for the new user provider.
(#17294) Remove empty puppet/provider/interface/base file

Without this patch there is a zero byte file located in the Puppet
library directory structure.  This is a problem because empty files are
considered errors when producing RPM packages.  I could not find any
reason this file exists, or any instances of this file being loaded.
Removing the file does not cause any apparent spec test failures.

This patch fixes the problem by removing the file from the tree.
Merge branch 'fix/3.0.x/17294_remove_empty_file' into 3.0.x

* fix/3.0.x/17294_remove_empty_file:
  (#17294) Remove empty puppet/provider/interface/base file