(#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>
(#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>
Merge pull request #1145 from daniel-pittman/bug/3.x/16327-inventory-service-fails-when-target-is-absent

#16327: inventory service fails when target is absent
Git ignore an .rvmrc file in the root of the project

Now that there is a Gemfile in the Puppet repository, RVM ignores an rvmrc in
the parent directory - because it assumes that the gemfile defines the full
scope of configuration required.

Since the gemfile is actually useless for the purpose, a project level rvmrc
file is needed to "win", and actually put local configuration in place.

Since things like that configuration are really per-developer, we should
ignore the file if present, though, so that we don't pollute everyone's
working space with our personal opinions on configuration.

Signed-off-by: Daniel Pittman <daniel@puppetlabs.com>
Merge remote-tracking branch 'origin/2.7.x' into 3.x

Conflicts:
	.gitignore

Signed-off-by: Daniel Pittman <daniel@puppetlabs.com>
(#4680) Reject CA network operations when master CA is disabled

When the master has CA function explicitly disabled, it would still respond to
networked REST requests. They accessed the local certificate store and,
generally, provided quite unexpected results.

For example, if a CSR was submitted it would be accepted successfully and
ignored; no further action, despite the fact that the master would never do
anything with it, and it could not be acted on.

Now, instead, we explicitly fail for remote requests.  This delivers a clear,
unambiguous error message to the agent and stops them functioning - a much
better outcome overall.

Signed-off-by: Daniel Pittman <daniel@puppetlabs.com>
Merge pull request #1144 from grimradical/tickets/3.0.x/15768

(#15768) Deprecate ActiveRecord-based storeconfigs
Merge pull request #1156 from daniel-pittman/bug/2.7.x/4680-better-handling-of-csr-submission-problems

(#4680) Reject CA network operations when master CA is disabled
(#2888) Add settings catalog info to README_DEVELOPER

Without this patch the README_DEVELOPER doesn't mention the special
settings catalog which I overlooked while working on #2888.  If the
settings catalog was in mind while I worked on this issue I probably
would have solved it a lot faster than it took to track down.

In particular, wrapping the File.open method was an effective way to
quickly track down the codepath that was improperly writing and
truncating the lockfile.
(#2888) Fix race condition with puppetdlockfile

Without this patch applied there is a race condition where by two or
more concurrent puppet agent processes will eventually result in a
deadlock state where all processes consider catalog runs to be
administratively disabled.

This is a problem because the configuration catalog stops being applied
periodically.  The system will not recover unless there is manual
intervention by the end user.

The problem is caused by the settings catalog.  The settings catalog
will contain a file resource for the puppetdlockfile if the file exists.
When two processes are running, the file will exist when it is created
by the other process.  When the file resource is in the settings
catalog, it will be created as a zero length file, or truncated to a
zero length file if it already exists.

Here is the state transition for two puppet agent --test processes, A
and B.

    A:
    lock()
      File.exist? => false
      File.open()
      catalog.run
      ...

    B:
    Puppet::Util::Settings#to_catalog
      File.exist? => true
      catalog.add_resource(Puppet::Type::File)
      ...
      resource synchronizes
      Puppet::Type::File#write(:content)

    A:
    unlock()
      unlink()

    B:
    settings catalog apply
      File.open("puppetdlock", "wb") { ... } # Truncates the file!

    A:
    locked? => true
    mine? => false

    B:
    locked? => true
    mine? => false

    A and B are deadlocked.

This patch fixes the problem by marking the puppetdlockfile settings as
a `:type => :setting`.  This change prevents the settings catalog from
containing a file resource for the puppetdlockfile setting.

Paired-with: Josh Cooper <josh@puppetlabs.com>
Merge remote-tracking branch 'upstream/2.7.x' into 3.x

* upstream/2.7.x:
  (#4680) Reject CA network operations when master CA is disabled

Conflicts:
	lib/puppet/indirector/request.rb
	spec/unit/indirector/request_spec.rb
Merge branch 'bug/2.7.x/2888_fix_puppetdlock_deadlock' into 2.7.x

* bug/2.7.x/2888_fix_puppetdlock_deadlock:
  (#2888) Fix race condition with puppetdlockfile
  (#2888) Add settings catalog info to README_DEVELOPER
Merge branch '2.7.x' into 3.x

* 2.7.x:
  (#2888) Fix race condition with puppetdlockfile
  (#2888) Add settings catalog info to README_DEVELOPER

Conflicts:
	lib/puppet/defaults.rb
	spec/integration/defaults_spec.rb
(Maint) Remove fragile test

This test began to fail with

  1) Puppet::SSL::Key should default to the :file terminus
       Failure/Error: @class.indirection.terminus_class.should == :file
         expected: :file
              got: :disabled_ca (using ==)
         Diff:
         @@ -1,2 +1,2 @@
         -:file
         +:disabled_ca
       # ./spec/unit/ssl/key_spec.rb:20

which was caused by other tests setting the terminus_class for the
Puppet::SSL::Key class. Since this is testing no interesting logic and
just looking at a default (that can be changed and not recovered), I'm
just removing the test.
Merge remote-tracking branch 'upstream/2.7.x' into 3.x

* upstream/2.7.x:
  (Maint) Remove fragile test
(#16430) acceptance: refactor zone tests

This patch adds new tests to zones, and corrects the earlier zone test cases
so that they take less time by eliminating redundant operations, and making
the zone creation use the default zpool
(#16430) acceptance: refactor cron tests

Changes:
- This patch refactors the cron tests and moves the common code to common_utils.
- This also adds test cases that checks for idempotence and array handling.
- It also removes the randomized users created, and uses a fixed user 'tstuser'
  for cron creation. This was done because using a randomized name such as plddddd
  did not buy us any thing while using a fixed user name gives us better
  predictability on the requirements of system under test
  (mainly that tstuser should be absent).