Previously, autorequiring of values was failing when ensure absent,
because the validate method wasn't splitting the path.

Now the validation method is just value_split.

Previously, we were not retrieving the current state of an existing
registry value and were not handling non-string registry value types.

This commit allows all registry types except array to be managed (create,
delete, modify).

Previously, trying to set the default registry value would fail because
puppet would fail to parse the parameter named `default` as that is a
reserved word. Changed the name of the parameter to isdefault.

The previous commit introduced windows line endings. This removes them
(only white-space change, no content change).

Just removing whitespace.

Previously, we allowed key paths to end in backslashes and we allowed key
names to be more than 255 characters, which are both wrong.

This commit uses a regex to perform better validation. It also adds
better tests, and to ensure that the capture of the repeating capture
group works (for more than a single level).

Previously, there was a separate parameter for specifying whether a
registry value is the unnamed (aka default). However, the following
example resulted in non unique paths:

  registry_value { 'hklm\foo':
    isdefault => true
  }
  registry_value { 'hklm\foo':
    isdefault => false
  }

The first value is managing the default value for the `hklm\foo` key. The
second value is managing the value named `foo` for the `hklm` key.

This commit eliminates this issue and eliminates the need for an isdefault
parameter. The above examples become:

  registry_value { 'hklm\foo\\':
  }
  registry_value { 'hklm\foo':
  }

Note, the trailing backslash must be escaped, since it is immediately
followed by a single quote.

Previously, the component parts of the key and value types were stored as
instance variables of the resource, even though they were derived from the
path parameter.

This commit introduces a KeyPath parameter which knows how to validate
registry key paths. It also contains the instance data associated with the
root key and subkey. The ValuePath parameter extends KeyPath and knows
about validating registry value paths, including how to handle default
values.

Uniquify path

Previously, autorequiring would not add relationships when resources mix
short and long forms of the root key, e.g. hklm and hkey_local_machine. It
also did not handle different cases, hklm vs HKLM.

This commit ensures that we always create a canonical path for the
`KeyPath` and `ValuePath`, which always use the downcased root key name.
In the process, the ascend logic was greatly simplified.

This commit does not fix general case-insensitivity in key and value
names, e.g. so hklm\Software and hklm\software are still seen as different
resources. This will be addressed in a separate commit.

Fix autorequiring when using different root key forms

Previously, the registry specific utility code was in the global
`Puppet::Util` namespace, which could lead to conflicts with puppet or
other modules.

This commit just moves them into the `Puppet::Modules::Registry`
namespace.

Use `Rspec.configure` to remove deprecation warning when running the spec
tests.

* rename-util:
  Remove rspec deprecation warning
  Rename registry-specific util code

Previously, we were going to support a `redirect` parameter to control on
a per-key and value basis whether to allow or disable registry
redirection. If allowed, then the OS would redirect puppet to the 32-bit
view of the registry. However, since it was a parameter, we could not
manage both the 32 and 64-bit versions of the same key in the same
manifest, due to the paths not being unique. And composite namevars
doesn't help.

This commit removes the redirect parameter and instead allows the key or
value path to be prefixed by `32:`. If specified, the 32-bit view of the
registry is used. If not-specified (default), the 64-bit view of the
registry is used.

Without this patch the examples of the registry key and value types and
providers are not up to date.  This is a problem because it can be hard
to quickly understand what the end user perspective and experience is
meant to be.

This patch fixes the problem by providing an example manifest with up to
date examples written with the perspective of the end user in mind.

* 32-bit:
  Add examples of current registry key and value types
  Add the ability to manage 32 and 64-bit keys/values

Previously, registry keys and values were including all of their
ancestors in the array returned by the `autorequire` block. If the catalog
contained those resources, then puppet was creating one dependency edge
between the registry key/value and each ancestor. This is not desirable,
as we only need one dependency edges between the resource and its nearest
ancestor that we're managing.

Also, registry values were autorequiring themselves.

This commit changes the autorequire blocks using the same logic as is used
in the file type. We walk our ancestors, looking for the nearest
registry_key that we're managing.

It also changes the `ascend` method to exclude the current resource from
enumeration, since both registry_key and registry_value had to do extra
work to exclude itself from the autorequire.

Also removed a spurious downcase method. Currently, we only canonicalize
the root key (to handled mixed case). A future commit will resolve
case-insensitivity for registry key paths and value path and names.

Previously, we were enumerating instances of
`Win32::Registry::PredefinedKey`, which failed since those objects don't
have a name method.

Changed it to enumerate the keys of the hash, which are the canonical root
key names, e.g. hklm.

This commit adds support for binary registry values. They must be hex
encoded strings with the high nibble first. The strings can be space
delimited, as is done in Microsoft's reg format, or omitted. So:

   deadbeef
   DE AD BE EF

Are both valid and equivalent. Empty string is also permitted.

This commit also adds better validation for dword and qword. The former is an
unsigned 32-bit integer, the latter unsigned 64-bit integer.

Support binary registry values

Without this patch the registry module blows up when installed onto a
Linux Puppet Master.  The utility code and the structure of the types
and providers end up requiring win32/registry which will never be
present on non-windows systems.  In addition, the types and providers
mix in module level support code, which does not work because of the
following Puppet bugs, all related to our inability to load utility code
from the $LOAD_PATH.

 * https://projects.puppetlabs.com/issues/3947
 * https://projects.puppetlabs.com/issues/4248
 * https://projects.puppetlabs.com/issues/14073

This has annoyed me enough that I'm going revisit these bugs and the
interplay of the modulepath, environments, and $LOAD_PATH.

…a_master

Work around #3947, #4248, #14073; load our utility code

Without this patch applied the registry type and provider do not have an
implementation for the following resource declaration.

    registry_value { 'HKLM\Software\Vendor\Bar\value_array':
      ensure => present,
      type   => array,
      data   => [ 'one', 'two', 'three' ],
    }

The `type => array` in the Puppet DSL maps to the REG_MULTI_SZ [1] data type.
This is basically an ordered list of null terminated strings with two null
bytes to denote the end of the list.

In Puppet we've implemented this as simply accepting an array for the data
property.  This implementation also works well with `puppet resource`:

    PS C:\> puppet resource registry_value HKLM\Software\Vendor\Bar\somearray
    registry_value { 'HKLM\Software\Vendor\Bar\somearray':
      ensure => 'present',
      data   => ['one', 'two', 'three'],
      type   => 'array',
    }

The change_to_s method on the data property has also been overriden to
display messages in the form of:

    data changed 'one,three,two,four' to 'one,two,three'

[1] http://msdn.microsoft.com/en-us/library/windows/desktop/ms724884.aspx

…tlabs-registry

* 'feature/master/multi_sz' of github.com:jeffmccune/puppetlabs-registry:
  Add REG_MULTI_SZ (type => array) implementation

Without this patch we don't have any easy to use examples of how to use
the registry types and providers.

This patch fixes the problem by including a defined resource type named
registry::service and an example class named registry::service_example.
After installing the registry module, the end user need only include
this class and the appropriate registry keys and values will be managed.

The current implementation requires a reboot for the services created by
these registry entries to show up in the Service Control Manager
(`services.msc`).

An example of how to use this new defined resource is:

      registry::service { 'PuppetExample1':
        display_name => "Puppet Example 1",
        description  => "Puppet Example Service 1",
        command      => 'C:\PuppetExample1.bat',
        start        => 'disabled',
      }

The README file didn't contain very good information about how to use
this module or how to use the types provided.  This patch provides
information about how to install the module and some examples of how to
use the `registry_key` and `registry_value` type.

* feature/master/service_example:
  Update README with info about the types provided
  Add registry::service defined resource example

Previously, puppet could only manage registry values as a 'minimal' set,
but not as an 'inclusive' set.

This commit adds a `purge_values` parameter to the registry_key type. If
set to true, puppet will purge all registry values associated with the
key that are not being managed by puppet. For example, if a key `foo`
contains values `bar`, `baz`, and puppet is only managing `baz` and
`qux`, then `bar` would be purged (deleted).

This patch does not purge registry keys that are children of a registry
key resource being managed.  It only purges values.

  registry_key { 'hklm\software\foo':
    ensure       => present,
    purge_values => true
  }
  registry_value { 'hklm\software\baz':
    ensure => present,
    type   => string,
    data   => 'val1'
  }
  registry_value { 'hklm\software\qux':
    ensure => present,
    type   => string,
    data   => 'val2'
  }

This commit satisfies the use-case where the user wants to specify the
exact set of values for a key and ensure that no other values exist
(without having to know what their names might be).

Add registry::purge_example class

This patch adds a class to the registry module to make it easier for the
user to see the behavior of the purge_values registry_key property.

The user needs to include the registry::purge_example class in the node
catalog, then set the following environment variables:

    PS C:\> $env:FACTER_PURGE_EXAMPLE_MODE = 'setup'
    PS C:\> puppet agent --test

This command will configure a registry key with a sub key and values
associated with the key.

    PS C:\> $env:FACTER_PURGE_EXAMPLE_MODE = 'purge'
    PS C:\> puppet agent --test

This command will configure a registry key with purge_values => true and
manage only half of the registry_value resources managed in the setup
phase.

* feature/master/registry_key_purge_values:
  Allow values associated with a registry key to be purged

Without this patch the registry module does not have a clear example of
how to use the `audit` metaparameter with `puppet inspect` and the
compliance feature of Puppet Enterprise.

This patch fixes the problem by including a
`registry::compliance_example` class the user may include in their
catalog.

Simply including the class will create a nested structure of registry
keys, subkeys, and values.  Once created, the resources should then be
switched into audit mode by setting
`$env:FACTER_REGISTRY_COMPLIANCE_EXAMPLE_MODE = 'audit'` and then
running `puppet agent --test` to obtain the new catalog with resources
set to audit mode rather than enforcement mode.

* feature/master/compliance_example:
  Add registry::compliance_example class to test compliance