Update packaging to account for hiera-puppet merge

Because hiera-puppet is now merged into 3.x, the debian and redhat packages
that used to depend upon hiera-puppet now provide hiera-puppet and should
uninstall/remove hiera-puppet upon upgrade. This commit adds the new
hiera-puppet binary to the packaging (extlookup2hiera) and also adds the
appropriate packaging directives to remove hiera-puppet packages before
installing.
Merge pull request #1134 from haus/maint/3.x/update_packaging_for_hiera_puppet_merge

Update packaging to account for hiera-puppet merge
(#16184) Improve example auth.conf

auth.conf was outdated and did not include examples of the allow_ip
and deny_ip functionality. I tightened up the text a bit, fixed
spelling and grammar, and tried to improve the clarity of the doc.
Merge pull request #1141 from ahpook/16184_auth_conf

(#16184) Improve example auth.conf
Merge pull request #1138 from vrthra/ticket/3.x/16383_solaris_acceptance_tests_updates

(#16383) solaris acceptance tests updates
(#16330) Update ZAML to latest upstream.

This rebases our internal ZAML on the upstream 0.1.3 release, including the
update to dual-license the code.  It then merges back all our changes and
squashes them into place - which, in essence, means bumping the version
number; we already had all the other relevant changes in place.

Signed-off-by: Daniel Pittman <daniel@puppetlabs.com>
Merge remote-tracking branch 'origin/2.7.x' into 3.x
Merge remote-tracking branch 'origin/3.x'
(#15768) Deprecate ActiveRecord-based storeconfigs terminuses

This deprecates the catalog, resource, and fact terminuses that
implement ActiveRecord-based storeconfigs functionality.
(#15678) Deprecate ActiveRecord-based inventory service terminuses

This deprecates the node and facts terminuses that implement the legacy,
ActiveRecord based inventory service.
(#15768) Deprecate puppet queue

The `queue` application is obviated by use of PuppetDB, which maintains
its own internal queueing system for storeconfigs.

Signed-off-by: Deepak Giridharagopal <deepak@puppetlabs.com>
(#16327) Fix fact terminus configuration cache handling

The facts terminus had a hook intended to configure the local YAML cache when
a remote terminus was in use. This worked as expected back in the 2.7 days,
but other changes have shifted it since then - and now it wasn't getting
invoked at the correct time to handle other configuration option changes.

This changes it to run the hook every time the terminus is changed, restoring
the correct behaviour when `facts_terminus` is set in the configuration file.

Signed-off-by: Daniel Pittman <daniel@puppetlabs.com>
(#16239) mock of facter :operatingsystem pending

Correct the typo missing :if=> in the previous
checkin 45e165016534b6c786d269a7825e72599c9beaa6
Merge pull request #1142 from vrthra/ticket/3.x/16239_mock_facter_operatingsystem_pending

(#16239) mock of facter :operatingsystem pending
Verified in Debina 6, and in Solaris11
(#16327) Continue agent run when node terminus find fails

When the agent starts a run it tries to fetch node data, in order to obtain
from the master idea of the environment it should be running in.  This allows
an ENC to fully control the environment of the agent.

If that isn't possible the agent can carry on - it may obtain a catalog in the
wrong environment, which will require that it fetch the catalog a second time,
so is quite a potential performance cost, even if a rare one.

Previously exceptions from the node terminus would abort the agent run, which
included cases where the terminus on the master failed to fetch data.

The case that discovered this was the `inventory_service` terminus for facts:
it was built with the assumption that it used a local YAML cache on the
master, and also talked to the remote server.

This was "too robust to fail" because the first time facts were found was
after they had just been saved in the compiler - an invariant that was true
until the agent started asking for the node definition.

In the case that no ENC was in use, and the inventory service was down,
though, the find operation would actually hard-fail, and that exception came
back down to the agent - and aborted the run.

This meant that it was impossible to bootstrap a node when the inventory
service was down: until you had submitted facts you couldn't get the node
data, but until you got node data the agent would never submit facts.

This simply expands the tolerance of the agent to node lookup failures:
because the worst case is that we compile the catalog a second time, in the
rare case of mismatch *and* your external service being down, this is
fairly safe.

Certainly, much safer than simply ignoring the node definition error on the
server, or not reporting it to other API consumers - who may actually care to
know that they couldn't get the data, or may not be able to operate
without it.

Signed-off-by: Daniel Pittman <daniel@puppetlabs.com>
(packaging) adds ips support for shipping and signing

This patch is complementary to the patch that adds shipping and signing support
for IPS to the packaging repo. It adds the variables ips_repo, ips_store, ips_host
Merge pull request #1146 from vrthra/packaging/ips_support

(packaging) adds ips support for shipping and signing
Merging as the complementary patch was merged into packaging in https://github.com/puppetlabs/packaging/commit/4778a0d010580325b0e89d69418fcd120f6a4f24
(#16425) ensure that first time install of speciifc version works

Previously if a specific version was requested, and it was the first time, the package installation
errored out due to passing the current version :absent to version compare. This patch verifies that
we do not pass absent to version compare if we know it is absent in the system currently.
Merge pull request #1147 from vrthra/ticket/3.x/16425_fix_ips_install

(#16425) ensure that first time install of speciifc version works
(#16189) Make --run_mode a global option and not a setting

In #16189 the problem is described as config print and --configprint
disagree. That problem was caused by the option --mode RUNMODE defined
in FaceBase not having any effect thus making 'user' be the only runmode
available to any Face.

Rather than implementing another way of modifying the run_mode (as
attempted in FaceBase), this commit makes the previously 'read-only'
global setting --run_mode settable from the command line and promotes it
from being a setting to a special case around the loading of settings.

In order to make this global run_mode the default, the Application class
now picks up the default from Settings (where run_mode is handled), and
thus the default becomes either the runmode set from the command line,
or 'user' which Settings has a fallback (default default).

Applications (such as Master) can still set run_mode as part of
application initialization - it works as before.

Unused/non working code relating to this is removed.
Documentation referring to --mode updated.