(#7316) Add method to expand autoloaded paths

Several places use an Autoloader to list files that could be loaded
relative to some prefix, e.g. puppet/application. But then the same
prefix is specified again when requiring a specific instance, e.g.

    require File.join('puppet', 'application', name)

This commit adds an Autoload instance method to expand a path, so the
above becomes:

    require @loader.expand(name)
tagmail: s/reportform/reportfrom/

Fix trivial typo in description of the `reportfrom` config option.

This coincides with a similar fix in
`puppet-docs/source/references/*/report.markdown` and is needed
to prevent the typo from propagating into the docs.

Signed-off-by: Paul Morgan <jumanjiman@gmail.com>
(#18041) Remove Autoload.list_loaded method

The list_loaded method was broken in 6700adca in 0.24.0, because the
yielded `hash` parameter was always nil -- we're collecting on a sorted
array of keys, not the `loaded` hash.

Since anyone calling this method would always receive a NoMethodError,
and the code is never called from anywhere in puppet or spec, it is safe
to remove without deprecation.
(#7316) Refactor listing and requiring of applications

Previously, the logic for listing and requiring applications was in two
places, CommandLine and Application, respectively.

The CommandLine contained logic, basically duplicated from the
Autoloader, to walk a search path and generate a list unique
applications relative to 'puppet/application'.

The Application contained logic for requiring the application from
'puppet/application', duplicating the logic from CommandLine.

This commit moves the logic for listing available applications to the
Application class, which delegates to its autoloader. Note the
autoloader already takes gem and module paths into account, so no change
in functionality there.

This commit also deprecates the CommandLine available_subcomands
instance and class methods.
(#7316) List faces using an autoloader

Previously, calling Puppet::Interface.faces generated a
different list of face applications than those included in
Puppet::Application.available_application_names, since the former only
considered the $LOAD_PATH, and the latter used an Autoloader, which
includes gem directories and the current environment's modulepath.

From what I can tell, the method is never used, as puppet itself
accesses faces via Puppet::Interface[name, version] method. However, if
someone had called `faces` it would have excluded faces that could be
loaded via require.
(#7316) Append module plugin directories to $LOAD_PATH

Previously, face applications delivered as a module could not be loaded.
This is because FaceCollection has problems loading code. For one, it
require's faces and actions within, but load's actions that reside in
different files. So it conceivable that a reloaded face application
could run with older faces, but newer actions.

Second, if we load the face, it will call Puppet::Interface.define,
which will check if the face has already been loaded by calling
FaceCollection[name, version]. But that will attempt to load the face
that we're currently loading, getting into an infinite loop.

Third, the help face application gets a list of available application
names from Application. This list includes applications from gem and
module paths. However, the help face application fails to load faces
which reside in the modulepath, since it's using require and not going
through the Autoloader.

While faces could be modified to use an Autoloader, the longer term plan
is to stop pretending we can reload code in ruby, i.e. always require
based on the current $LOAD_PATH.

This commit adds a `each_plugin_directory` method that yields each
module plugin directories based on the current environment. It also
modifies the CommandLine to append those directories,  unless we are
loading the master or agent applications.

In the case of an agent, the libdir is always in the $LOAD_PATH, and it
will load pluginsync'ed files from there. This aspect of #4248 has been
fixed for sometime.

In the case of master, we compile catalogs in the context of the
client's environment, not necessarily the environment the master itself
is configured to use. As such, we only want to autoload custom functions
from those modules, not require them. In other words, we don't want those
modules in the $LOAD_PATH to start with. This aspect of #4248 (the
ability to load utility module code from a custom function) is not
fixed, and can't really be fixed until we move to one process per
environment compilation.

In the case of apply, we compile catalogs, but always in its current
environment, so we can safely append to the $LOAD_PATH. And same for
face applications. As a result, the help face can load other faces from
modules.
(#7316) Warn if script action is reloaded

In commit 6f38feba for #12763, we no longer prevent actions from being
reloaded, e.g. during pluginsync. But this only applies for "normal"
actions, not script actions.

This commit makes a similar change for script actions so they're
consistent.

With that said, the whole reloading of actions is dubious. If the action
is declared within the body of the face, then the action will be
required along with the face, and neither can be reloaded. Only if the
action is in a separate file will it be loaded via the Autoloader, and
therefore be reloadable.

Also, it doesn't appear we can reload default actions, though we can
reload script actions (if they were originally loaded).
(#7316) Add acceptance test for loading face from module

This acceptance tests verifies that we can load a face application from
an environment-specific modulepath. It ensures the face is an available
application, that we can get help for the face, and that we can execute
a simple action, and an action that requires utility code to perform the
action.
(#18047) Revert change to user confdir

In 3.0, the default user confdir (and vardir) was changed from ~/.puppet
to the Dir::LOCAL_APPDATA/PuppetLabs. However, when puppet is run as a
non-administrator, puppet will attempt to create its confdir, e.g.
C:\Users\albert\AppData\Local\PuppetLabs\puppet, and fail because the
parent PuppetLabs directory doesn't exist.

This wasn't an issue in 2.7.x, because the confdir was ~/.puppet, so the
parent directory always existed.

This commit restores the previous behavior for non-administrators. No
changes are required for administrators, because the MSI installer creates
the necessary directories within COMMON_APPDATA.
Merge pull request #1324 from joshcooper/ticket/3.0.x/18047-revert-user-confdir

(#18047) Revert change to user confdir
Merge pull request #1320 from jumanjiman/reportfrom

tagmail: s/reportform/reportfrom/
(Maint) Clarify what the options to less are

The comment for an assignment to the LESS environment variable didn't
provide any insight into what was being done. This expands on the
comment so that the reader can know a bit better what all of "random"
letters mean.
Update PUPPETVERSION to 3.0.2-rc2
(#7316) List subcommands in a supported manner

The man face's call to `available_subcommands` was missed when that
method was deprecated. This makes sure it calls the new method.
Merge remote-tracking branch 'origin/3.0.x'
(Maint) Allow creating a test file with default options

Previously even an empty hash of options needed to be specified, this
allows it to be left off to get the defaults.
(#7316) Use tempfile utilities for managing files
(Maint) Fix syntax error in module generate template

Commit 0d3b84249 introduced a syntax error in the template for
generating the init.pp file. This fixes that syntax error.
(#7316) Test faces from modules using a module

Previously the test that we could load faces from modules did so by
constructing a module in the configured modulepath. A more complete test
is to install a module that contains a face and ensure that we can
execute the face that has been installed in that manner. This commit
changes the test to do that.
(#7316) Do not run on windows

Because the test uses the module tool, this test cannot be run on
windows.