(#15529) Initialize app settings before all and each test

Adds a new initialize() call to the TestHelper API, designed to be run before
all testing and further loading commences.

It initializes Puppet settings using the proper initialize_app_defaults call
rather than setting items individually, so the settings class correctly states
the app has been initialized.  This then makes the autoloader set up paths as
it queries this value to determine if the libdir and others have been set up
and it can autoload from them.

Patch modified by Josh Cooper <josh@puppetlabs.com>
 (#15529) Initialize settings before executing puppet specs

Previously, Puppet's settings were not initialized until the first
example was executed. Depending on the test being executed, this could
cause errors that $confdir was not initialized. For example, if the
first spec test to be executed contained:

    Puppet::Interface.faces.each do |name|
      it "should ... #{name}" do
        ..
      end
    end

Then the test would blow up, since the call to `faces` happens before
the spec_helper's before each block is executed.

This commit ensures Puppet's application default settings have been
initialized before any test code executes. A similar change will need to
be made in puppet_spec_helper.
(Maint) Cleanup tests for owner to actually test the logic

The previous tests around the owner behavior for a file setting did very
little to test the logic around what actual owner will be used when.
This commit changes the tests to make them more clearly define the
behavior of the owner selection.
(Maint) Cleanup tests for group to actually test the logic

The previous tests for group behaviour of the file setting was not very
clear as to the logic it tried to implement. This changes the tests and
makes clear that the group behavior is a little odd in that if 'root' is
specified it still uses the service group.
(Maint) Move variable closer to point of use
(Maint) Remove duplicate tests

Now that the behavior around selecting the right owner and group is
explicitly tested there is no need for the tests around the internal
method to determine whether to use a service user or not. This removes
those tests and fixes up the names of some of the replacement tests.
(Maint) Clarify error message for invalid group and owner

The previous error message for an invalid owner looked like:

  Error: Could not intialize global default settings: Internal error: The :owner setting for Where Puppet stores dynamic and growing data.  The default for this setting is calculated specially, like `confdir`_.: vardir must be either 'root' or 'service', not 'gnats'

That message was not very clear as to what had just gone wrong because
it is providing far too much information. This commit changes the
message too:

  Error: Could not intialize global default settings: The :owner parameter for the setting 'vardir' must be either 'root' or 'service', not 'gnats'

This applies to both the owner and group parameters.
(Maint) Show the actual allowed values for group

The error message for the group parameter had gotten out of sync with
what the allowed values actually were. This updates the message to
include all of the allowed values.
(Maint) Remove duplication in parameter checking
(#9862) Allow group to be root

The previous behavior allowed the group parameter to be set to root, but
it still selected the configured "service" group. This is contrary to
what is done for the owner parameter and seems to have been an
accidental behavior.

This commit brings this portion of the group handling in line with user.
(#9862) Do not manage the group if it doesn't exist

The previous behavior for managing the group of a file meant that if the
group didn't exist puppet errored when trying to set permissions. This
changes the behavior to check for the existance of the group and in the
case of the group not existing (and we don't expect it to be created
because `:mkusers` is false) then the group is not managed.

There were several alternatives that were possible:

  * use the primary group of the "root" user
  * use the primary group of the `:owner` for the file

Neither of these were compellingly better alternatives, since this
should only be happening when puppet hasn't been fully configured on the
system.
(Maint) Invert logic to make it more straightforward

The logic for testing if a group or user were available tried to
short-circuit, but ended up being less clear than if it just branched.
It also created a variable that wasn't actually used later.
(#9862) Add acceptance test for issue

This checks to make sure that when puppet is run without a specific
user/group present it doesn't fail. Instead it just ignores the given
user. When a user/group is present then it will manage the ownership.
Update lib/puppet/version.rb for 3.0.2
Merge branch '3.0.x'

* 3.0.x:
  Update lib/puppet/version.rb for 3.0.2
(Maint) Ensure tests are hitting the right ascpect

The previous tests were not very careful about making sure that they
were going to be going down the right branches to test the path that
they wanted. This makes some of the branch selection more explicit so
make the tests a bit more robust to change.
(#9862) Promote user/group logic to first class

Some core logic of the setting, which is how to manage the user and
group, was hidden inside obtuse if conditions. This tries to make it
clearer what is happening, at the expense of being longer, by promoting
the different values available for owner and group to classes that can
contain the logic for how to deal with that particular value.
Add postflight for OSX packages to add puppet user, group

Previously, users installing the Puppet package for OS X would need to create
their own user and group to run `puppet apply` successfully or to set up a
puppet master. This also was out of line wiht our other puppet packages, which
do create the puppet user and group. This commit adds a postflight script to
the OS X packaging that will create a puppet user and group if they don't
already exist.

Note: this commit depends on packaging changes to install the postflight during
OS X packaging and will be inert until that change is made.
(#18298) Make useradd use osfamily not operatingsystem

This patch addresses ticket #18298 and uses the osfamily fact instead of
the operatingsystem fact. This change allows us to decouple the list of
RedHat derivatives from the useradd provider and rely on the osfamily
fact.
(maint) Whitespace only cleanup of useradd provider

Cleans up whitespace issues found while hacking on the useradd provider.