(#8193) Support new keytypes for ssh_authorized_key

Recent versions of openssh (at least openssh 5.8) support the following
keytypes in in the authorized_keys file: ecdsa-sha2-nistp256,
ecdsa-sha2-nistp384, ecdsa-sha2-nistp521, ssh-dss or ssh-rsa.

Add support for ecdsa-sha2-nistp256, ecdsa-sha2-nistp384 and
ecdsa-sha2-nistp521.
(#8193) Support new keytypes for sshkey

Recent versions of openssh (at least openssh 5.8) support the following
keytypes in in the authorized_keys file: ecdsa-sha2-nistp256,
ecdsa-sha2-nistp384, ecdsa-sha2-nistp521, ssh-dss or ssh-rsa.

Add support for ecdsa-sha2-nistp256, ecdsa-sha2-nistp384 and
ecdsa-sha2-nistp521.
(#8193) Add unit tests for new ssh keytypes

Add unit tests to prove that the ssh_authorized_key provider can parse
all different keytypes. This currently shows that the provider lacks
support for ecdsa-sha2-nistp256, ecdsa-sha2-nistp384, and
ecdsa-sha2-nistp521 keys.
(#8193) Add support for new ssh keytypes in authorized_key provider

The provider now correctly detects lines that describe an
ecdsa-sha2-nistp256, ecdsa-sha2-nistp384 or ecdsa-sha2-nistp521 key.
maint: Unify 'type' and 'classref' non-terminals in the grammar

These both wrapped the CLASSREF token, except 'type' created an
AST::Type object, whereas 'classref' just extracted the string value.
This change removes the 'classref' non-terminal, replacing its uses with
'type' and explicitly extracting the string value from the AST::Type
instance.

Ideally, this should probably either retain the AST::Type object and
evaluate it where it's used, or remove the AST::Type leaf entirely, as
it has no actual behavior of its own.

Also removed some dead warnings (they were warning on a lower-case type,
which can't happen).
(#6710) Support relationship arrows between resource refs with title arrays

Previously, a relationship such as

  Notify[a,b] -> Notify[c,d]

would fail, because relationship objects didn't handle arrays of
resources, and tried to look them up as though the title array were a
single resource name. Now, relationships will be established for each
resource specified by the ref.
(#6710) Support relationships for resources defined by other constructs

This adds support for using a variable, resource ref-like string, case
statement, selector, or array/hash access for either side of a
relationship. For example, it is now legal (if unwise) to write the
following:

  notify { [a,b,c]: }
  $var = Notify[a]
  $var -> case 'x' {
    'x': {
      notify { d: }
    }
  } ~>
  'x' ? {
    'x' => Notify[b]
  } <- "Notify[c]"
(#11451) Fix improper use of "defined" in the duplicate declaration error

Duplicate resource declarations (including classes with the resource-like
class {'name':} syntax) were provoking the following error:

Duplicate definition: Class[Test] is already defined in file /tmp/test.pp at
line 9; cannot redefine at /tmp/test.pp:10 on node example.com

This is incorrect -- the problem is a duplicate declaration, not a duplicate
definition. I believe this is a holdover from our formerly sloppy use of the two
terms.

This commit fixes the error message, and renames several variables and methods
to match our current understanding of the terms "define" and "declare." Tests
are fixed as well.
Fix stage inheritance between multiple included classes

Commit 656eff8 introduced a regression whereby stages would only
propagate from a class to its direct descendants, and no further. This
means if a class A includes B which includes C, the stage specified for
class A would only be used for A and B, and would omit C.

This was due to a logic error around the recursive nature of class
evaluation. We would evaluate the outermost class, and while doing so,
would evaluate its children, and etc. The step after evaluate was to set
up the stage relationship, which would then happen in reverse order
(C and then B and then A) as the stack was unwound. This meant that C
would try to set its stage, see that it had no specified stage, and try
to use its parent's stage (B). B also had no specified stage,
so C fell back to main. The next step in the stack, however, was to set
B's stage, which would then be inherited from A.

The purpose for the breaking change was to move stage setup after
parameters were set, so that defaults could be used to set stage. So now
we move stage setup back a bit in processing, between parameter setup and
actual evaluation of the contained code (which is the step which will
eventually evaluate the children). This achieves the desired effect of
setting stages after parameters, but also correctly sets stages in
top-down order, allowing them to cascade naturally.

Included in this is a small change during compiler setup to add the
Settings class to the catalog *before* evaluate_code is called. This is
because evaluate_code will now add the class to the main stage, which
requires the resource know about its catalog. Since Settings is never
really executed on the agent in a meaningful way, adding it to stage
main has no practical effect, so this is a safe change.
Merge pull request #342 from daniel-pittman/refactor/2.6.x/11996-spec-failures-after-ruby-187-p357

(#11996) Fix test failures due to hash processing order changes.
Merge branch '2.6.x' into 2.7.x
(#11057) Note why a scheduled run was skipped in Puppet.

This adds the reason for skipping a run to the message about doing so, which
makes it easier to understand why it happened post-hoc.

Signed-off-by: Daniel Pittman <daniel@puppetlabs.com>
(#11057) Add spec, should notify why a run is skipped

Without this patch, there isn't any spec test coverage for this
particular bug and the behavior change introduced in this change set.

This patch fixes the problem by adding a spec test covering our
expectation that Puppet informs the user why a run is skipped.

The test makes the fundamental assumption this information is contained
within Puppet::Application.run_status which we're mocking.  The test
validates the information contained in
Puppet::Application.run_status is in fact shown to the user.
Merge branch 'bug/2.7.x/11057-debug-output-enhancement' into 2.7.x

* bug/2.7.x/11057-debug-output-enhancement:
  (#11057) Add spec, should notify why a run is skipped
  (#11057) Note why a scheduled run was skipped in Puppet.
Merge branch '2.7.x' of github.com:puppetlabs/puppet into 2.7.x
(maint) Fix test 3360 to use per host cfg data

Test harness formerly used a global config hash to store config data;
this breaks with the intoduction on non-posix hosts (windows).  Now
using a per host config hash.  Updating this test to use the new
style.  This will need to be merged into 2.7rc as well; already
applied to Master.
Merge pull request #354 from djm68/fix_test_3360_allow_duplicate_csr_with_option

Fix test 3360 allow duplicate csr with option
(Maint) Remove dead code

Removing dead code.
(#11930) Use FileUtils.mkdir_p to recursively create directories

Previously, `Puppet::Util::Log::DestFile` was using `Puppet.recmkdir`
to recursively create parent directories. However, the latter method
assumed POSIX-style paths and did not work on Windows.

Also, if the `Puppet.recmkdir` method failed to create any of the
parent directories, it would rescue the exception and return
false. However, `Puppet::Util::Log::DestFile` did not check the return
code, and would fail later when trying to create/open the file.

This commit removes the `Puppet.recmkdir` method and changes
`Puppet::Util::Log::DestFile` to use `FileUtils.mkdir_p` instead,
which works with both POSIX and Windows paths. This commit also
preserves the behavior of creating each parent directory with mode
`0755` (but not changing the mode for existing parents).

If one of the parent directories cannot be created, e.g. EACCES, the
`FileUtils.mkdir_p` method will raise an exception, similar to how
`File.open` would raise previously if one of its parent directories
could not be created.
(#11930) Use Puppet::Util.absolute_path? to validate paths

Previously, there were still some places where we were using a
POSIX-specific regex to validate fully-qualified paths, which fails
with Windows paths.

This commit just changes them to use `Puppet::Util.absolute_path?`,
which handles both POSIX and Windows paths, based on the platform
we're currently running on.