Incorporate Red Hat's NetworkManager fix into upstream

Red Hat/Fedora have been carrying a patch to restart puppet if
resolv.conf or other networking configuration settings are updated via
Network Manager.  We should be doing this as well, as it's a good idea.

The patch and problem are described in the following bugs:
https://projects.puppetlabs.com/issues/2776
https://bugzilla.redhat.com/532085

Note this only applies to rpms, and only to builds for EL/Fedora. This
patch/fix won't be applied/installed on any debian varient, sles, mac
etc.

Signed-off-by: Michael Stahnke <stahnma@puppetlabs.com>
Fixup to NetworkManager dispatcher to be compatible with systemd

The previous patch from Red Hat was only compatible with sysV init
systems. This patch modifies the script to enable systemd calls when
appropriate.

Signed-off-by: Michael Stahnke <stahnma@puppetlabs.com>
(#18187) Clear *root* environment when clearing caches

When changing settings or initializing Puppet via TestHelper, the
Puppet::Node::Environment.clear method is called to delete the cached
environment objects, as they may reference cached module paths based on old
values of settings.

The *root* environment is a special case, as it acts as the current environment
when no other environment has been created and set yet.  It can still have a
module path based on current settings, so it too should be cleared along with
other cached environments.

Failure to reinitialize *root* causes failures when initializing Puppet via the
TestHelper.  The Puppet::MetaType::Manager class uses the current environment
in calls to Puppet::Util::Autoload, which starts as the default *root*
enviroment.  The type loader is called a few times during TestHelper
initialization and so if the module path is then changed (which triggers a
.clear call), the *root* environment will contain paths based on old settings,
so types won't load.

Loading types based on the environment is new in 8173a6e6 (2.7.19).  3.x is
unaffected as caching of module paths doesn't begin until
app_defaults_initialized? changes to true.
Clarify example in comment for lookup_external_data_for

The comment implied that we would lookup external data for a required
argument, which is not true.
(#17522) Only print load errors to debug with non-specific context

Fixes a variable assignment that landed in the wrong branch during a conflict
merge (a4451fb1).  Commit a8575f41 fixed a spec failure but the original code
wasn't restored.

This restores the original functionality in #14136 where a non-specific
context (i.e. /files/etc) would be optimised (only load lenses for files under
/etc) but since it was vague, would only log load errors to debug.  Instead,
load errors were reported as warnings for non-specific contexts.

Load errors will continue to be reported as warnings for supplied contexts if
they're specific.