(#14615) Exclude helperscripts in gentoo service provider

The directory `/etc/init.d` does not only store normal initscripts but
also a few helper scripts (like `functions.sh`). The former behaviour was
to treat them as regular initscripts which can lead to dangerous results
especially when running `puppet resource service`. This command will
issue `/etc/init.d/<script> status` on every script inside
`/etc/init.d`. Because the helperscripts don't care about arguments,
this will cause the system to reboot when `/etc/init.d/reboot.sh status` is
executed.

Exclude helperscripts when searching inside `/etc/init.d`.
(Maint) Added test for fully qualified variables

A fully qualified variable looks up through the scopes of the scope that
the variable references.
(#14343) Lookup in correct inherited scope

The previous twoscope lookup of the inheritied scope tried to find the
inherited scope by looking up the class_scope() directly. Unfortunately,
this does not work correctly in cases where the inherited scope is
qualified to the topscope (::parent) or where the scope is implicitly
qualified (class a { class b {} class c inherits b {} }).

By using the same mechanism that variables use for looking up scope (the
qualified_scope() method) variable lookup will find a scope consistent
with what qualified variable lookups will find.
(#14297) Handle upstart services better

The previous changes to the upstart provider didn't take into account services
that may have upstart jobs in /etc/init with no corresponding symlink to
upstart-job in /etc/init.d. This fix adds /etc/init/$service.conf to the search
path in the upstart provider.

In order to allow upstart to use debian as its parent, this commit adds methods
for enabled?, enable and disable. Without this fix, using a debian style init
script on ubuntu requires manually specifying the debian provider be used.
With this commit, the upstart provider can be the default for ubuntu and
still fail up to its parent, debian.

The enabled?, disable, and enable methods are complicated because upstart has 3
behaviors to account for. Upstart < 0.6.7 have only the conf file and start on
stanzas to worry about, 0.6.7 < upstart < 0.9.0 has a manual stanza which
removes any previous start on declaration, and upstart >= 0.9.0 has an override
file. In upstart >= 0.9.0, the provider does all of its work using override files
to leave the upstart conf file for the service intact and unchanged.

Because of the need to know which upstart version is being used, this commit
also adds a method and a class variable to hold and access the upstart version,
obtained by a call to `initctl --version`.
(#14297) Update spec tests for upstart provider

This commit adds tests for the upstart provider to verify that it has the
enableable methods and that it behaves correctly with various versions of
upstart. The tests include multiline start blocks, manual stanzas, and override
files.
(#14297) Add acceptance test for upstart provider

This adds a simple upstart provider test to the acceptance tests. It has some
basic service cases to consider, including an upstart job with a symlink in
/etc/init.d, an upstart job with no symlink in /etc/init.d, and a init script
that is not an upstart job. The test was graciously supplied by Justin Stoller.
(#14343) Test cases for more forms of variable lookup

* ensure that topscope variable lookup works when inheriting
  from a fully qualified class name.
* ensure that local scope overrides inherited scope variables
(#14297) Clean up upstart provider and tests

This commit eases readability of the changes to the upstart provider, breaking
functionality into helper functions where appropriate. The spec tests were
similarly cleaned up.
(#14297) Update upstart provider acceptance tests

Previously this test would grep the status output to determine the status of
the service. That works for upstart services, but not for init style services.
For those the return code of status must be checked. This commit adds a wrapper
function to handle using the right method to determine the service status.
Merge remote-tracking branch 'zaphod42/bug/2.7rc/14343-variable-lookup-fails-with-qualified-classes-in-inheritance' into 2.7rc

* zaphod42/bug/2.7rc/14343-variable-lookup-fails-with-qualified-classes-in-inheritance:
  (#14343) Test cases for more forms of variable lookup
  (#14343) Lookup in correct inherited scope
  (Maint) Added test for fully qualified variables
(#14297) Define agent in upstart acceptance test

agent wasn't being passed into the helper function in the upstart acceptance
test, so this adds the agent variable to the method and passes it in when
called.
(#14297) Don't remove tty1 or rsyslog during upstart acceptance

Previously the upstart acceptance would try to remove the tty1 and rsyslog
packages, which could cause unexpected behavior in the acceptance tests after
the upstart test was handled. This also removes apache after the test
concludes, but leaves tty2 and rsyslog intact.
Merge remote-tracking branch 'haus/ticket/2.7rc/14297_handle_upstart_better' into 2.7rc

* haus/ticket/2.7rc/14297_handle_upstart_better:
  (#14297) Don't remove tty1 or rsyslog during upstart acceptance
  (#14297) Define agent in upstart acceptance test
  (#14297) Update upstart provider acceptance tests
  (#14297) Clean up upstart provider and tests
  (#14297) Add acceptance test for upstart provider
  (#14297) Update spec tests for upstart provider
  (#14297) Handle upstart services better
(#14723) Fix http report description
Update CHANGELOG, conf/redhat/puppet.spec for 2.7.15rc3
Merge branch '2.7rc' into 2.7.x
(Maint) Close filehandles after read in upstart

Not closing the filehandle after reading leaves a File object floating
around with an open handle. On unix systems this is ok, but on Windows
this causes a problem for the subsequent move of the new file into
place.

This changes to reading of a file to ensure that the file handle is
closed after we finish reading.
Merge pull request #825 from zaphod42/maint/2.7rc/leaked-filehandles-in-upstart

Maint/2.7rc/leaked filehandles in upstart
maint: Make it easier to test the service provider

Before the change the directories to search for initscripts (e.g.
`/etc/init.d`, `/sbin/init.d`) were stored in a class variable that was
calculated at load time. This way stubbing `operatingsystem` in test
cases did not change the value of `@defpath`.

Turning the class variable in a class method. This way stubbing
operatingsystem does change the result when querying defpath. The fact
lookup should be relativly cheap so we do not have to cache the
value in a class variable.
(#14615) Fix provider spec tests to work on non gentoo systems

The gentoo service provider tests made the assumption that /etc/init.d
is always the directory where the service provider will look for init
scripts while in fact the path depends on the operatingsystem.

The service provider spec also made the assumption that the sshd init
script is present on the target machine.

Stub the operatingsystem fact to prevent failures.
Stub the stat-call so the sshd script is always considered present.