(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.
(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.
(#9862) Document management of file owners and groups

This adds YARD docs for methods and classes that are part of managing
owners and groups of files (and directories).
(#18298) Use `==` not `include?` in useradd provider

Andy raised the concern we should use `==` instead of `include?` since
we are checking a single value. This commit addresses the concern.
(maint) Fix spec failure in hiera_spec

Without this patch applied Puppet behavior tests are failing against
Hiera master because of the addition of a new, backwards-compatible,
default setting named `merge_behavior`.  This setting defaults to
`:native` and has no change in behavior in the default case.  The specs
are failing because they compare against the entire list of default
settings, comprehensively.

This patch addresses the problem by updating the list of default
settings to match Hiera master.

The related patch in Hiera is 4ac8372, "Add deep-merge feature to
backend lookups"
Merge branch 'fix/3.0.x/hiera_default_config_spec' into 3.0.x

* fix/3.0.x/hiera_default_config_spec:
  (maint) Fix spec failure in hiera_spec
Merge branch '3.0.x'

* 3.0.x:
  (maint) Fix spec failure in hiera_spec
Merge pull request #1344 from zaphod42/issue/master/9862-cannot-run-without-puppet-group

(#9862) Fix puppet cannot run without puppet group on the system
(#17371) Re-initialize settings metadata after run_mode determined

Currently metadata for settings (e.g. mode, owner) is initialized during
parsing of the config file, at which point the run_mode isn't known.  The
initialization loops over each section of the config and since one of the
sections is determined by the run_mode, this means it doesn't get searched.
Setting file metadata inside a section such as [master] has no effect.

This patch causes the setting metadata to be set twice - once during early
startup before the run_mode is known (for settings used globally) and again
once the run_mode is known so that configuration in specialised sections take
effect.