(Maint) Removed commented out settings

These settings were commented out. I think we have already done
something else to support those use cases, and if we haven't...well,
that is what version control is for.
(Maint) Restructure requires for settings

The settings classes were not loaded in a robust manner. Some required
other files with the knowledge that the right modules would be created.
This caused a duplication of requires (which can cause a small slowdown
as ruby looks up whether the code has already been loaded). By requiring
the settings *after* the settings class has been opened, we can avoid a
lot of this extra work and overhead.
(#22205) Add enum setting type

It is often useful to be able to restrict the valid values for a setting
to a known set. This adds an :enum setting type that can take a :values
array, which defines the allowed values. If the value given for the
setting is now found in the list of allowed values, then it will throw
an error.
(#22205) Provide setting to control manifest ordering

The default ordering for manifests is something that is useful to be
able to control. This provides an setting that will be used to select
between the pre-#18508 and post-#18508 ordering mechanism.
(#22205) Re-introduce old ordering as a Prioritizer

This creates an old prioritizer for resources as it existed in commit
f51e967b73ff0154801f514aff40ca524bdd8ab1.
(#22205) Chose a Prioritizer based on Puppet[:ordering]

This ties the selection of the Puppet::Graph::Prioritizer to the
Puppet[:ordering] setting. In order to make it easier to ensure that all
of the uses of the prioritizer use the same one (because it needs to
track state) this also moves around the relationship of the catalog and
the transaction. Previously the catalog was responsible for converting
itself into a relationship graph. This now puts that responsibility on
the transaction, which much now be constructed with the desired
Prioritizer. The selection is still done in the catalog (because that is
where #apply lives, which is the public starting point of applying a
catalog).

Additionally this adds a random prioritizer.
(#22205) Extract common Prioritizer code into a superclass

All of the prioritizers had the same code to track priorities already
produced. This pulls that into a superclass.
Merge pull request #1840 from zaphod42/feature/master/22205-setting-to-control-default-ordering

(#22205) Provide setting to control manifest ordering
(#22191) Add cancelled resource handler

This commit adds the ability to pass a cancelled resource handler callback
to the traverse method such that if the traversal is cancelled, then the
callback is invoked once for each resource that is ready, but not yet
evaluated.

In addition, the resource is "finished", which unblocks its dependents, so
that the callback can handle those as well.

While writing tests for this, we found a bug in the main while loop.
Previously, the loop was removing the next ready resource, and then checking
if the loop had been cancelled. But if the loop was ever cancelled, the removed
resource was effectively lost. This commit reverses the order so that we only
remove the next ready resource if we intend to evaluate it.

Paired-with: Patrick Carlisle <patrick@puppetlabs.com>
(#22191) Mark ready, but unevaluated resources, as skipped

Previously, if a transaction was cancelled while processing resources, the
report did not contain any information about the skipped resources.

This commit modifies the transaction to supply a cancelled_resource_handler
callback, which if invoked, will generate a resource status object for the
resource, and mark the status as skipped.

This commit also updates the test helper to clear the run_status global
state before each test.

Paired-with: Patrick Carlisle <patrick@puppetlabs.com>
(#22191) Always process internal catalogs

Puppet generates and applies several catalogs during a single run. There is
the main (host_config) catalog, either downloaded from the master, or locally
applied. However, there are several other internally generated catalogs used
to manage internal state, such as file permissions from defaults.rb. Basically
anytime `Puppet::Settings.use` is called.

Previously, if puppet was asked to stop, `Puppet::Application.stop!`, then it
would cancel the current transaction, as well as any future transaction. As a
result, we may intentionally cancel the main (host_config) catalog, but then
unintentionally skip the transactions that follow, e.g. writing the rrdgraph
report.

This commit modifies the transaction to only cancel the evaluation loop if we
are evaluating the main (host_config) catalog and a stop has been requested.
All other internal catalogs will always be processed.
(#22191) Rename cancelled to canceled

Prefer the current American spelling from the past 30 years.
Merge branch 'ticket/master/22191-mark_skipped_resources'

* ticket/master/22191-mark_skipped_resources:
  (#22191) Rename cancelled to canceled
  (#22191) Always process internal catalogs
  (#22191) Mark ready, but unevaluated resources, as skipped
  (#22191) Add cancelled resource handler
use :if so rspec sees the test even if it's not executed
(#22206) Add option to disable default schedules
Use Dir.glob(), don't require rubygems or rake, use Dir.chdir as a block
(#22205) Select manifest ordering for ordering test

This test was missed when the manifest ordering was changed to being a
setting. The test, of course, fails without having the manifest ordering
being selected.
(#22205) Reinstate relationship_graph as a factory method

The Puppet::Catalog#relationship_graph method used to be a factory for
the Puppet::Graph::RelationshipGraph. That was removed when the
prioritizer was added in an attempt to remove some of the
responsibilities of catalog. Inside puppet, all of the consumers were
updated. Unfortunately many tests of types rely on the old behavior in
order to test eval_generate, which may be implemented using
introspection of the relationship graph. This reverts back to the old
behavior of the relationship_graph being a factory method and instead
memoizes the prioritizer so that the same instance can be used for the
relationship_graph as well as the transaction.
Merge pull request #1843 from zaphod42/issue/master/22205-revert-relationship_graph-to-being-factory-method

(#22205) Reinstate relationship_graph as a factory method
(Maint) Add docs for #relationship_graph