Without this patch the registry module isn't really setup to run the
test suite in an automated way.

This patch adds a copy of the watchr.rb file from the stdlib module.  We
might consider including this in the spec helper repository itself.

To use:

    watchr spec/watchr.rb

Then simply edit any ruby file in the module and the tests will
automatically run.  You might also need to setup
`~/.watchr_images/failed.png` and `~/.watchr_images/passed.png` to get
pretty Growl integration.

Issuing CTRL-\ will run the test suite on demand.

Without this patch, the Win32 library and API are tangled up in both the
type and provider.  The type should not have any Win32 specific logic,
as this code is meant to be run on the Puppet Master and compiler nodes.

This patch fixes the problem by separating out helper methods into two
separate modules.

This patch introduces two new classes, RegistryValuePath and
RegistryKeyPath.  These two classes have slightly different semantics
for what a subkey is.  These classes are strictly meant to perform
manipulation of a registry path string.

This patch separates out the Win32 API into
Puppet::Modules::Registry::ProviderBase which implements instance
methods meant to be mixed into the provider classes.

The patch removes all of the Win32 API logic hanging off of the path
parameter instance itself.  All of this logic is moved into instance
methods of the provider itself instead of the parameter.  This is
necessary to separate out the behavior from the type instances itself,
which share the parameter instances.

Without this patch the spec tests do not pass on a Unix system.  Since
all of the Win32 specific logic is removed from the type by this patch
the spec tests now pass on Unix systems.

Without this patch not all of the properties and parameters are
documented.  This patch fixes the problem by adding desc strings to all
of the parameters for both the key and value registry types.

…rovider_helper_methods

Separate the implementation of the type and provider

Without this patch there are no acceptance tests for the Puppet Labs
registry module.  This is a problem because we need to ensure the
registry_key and registry_value providers actually manage the registry
as expected.

This patch partially fixes the problem by adding a single acceptance
test.  This is a partial fix because I want to lay all of the groundwork
for additional acceptance tests first, then add additional tests in
subsequent patches.

This patch introduces a Ruby module named Systest::Util::Registry.  This
module is meant to be mixed into the eigenclass of a specific test case.
All of the helper methods will then be available to the test case
instance.

A single test case example is provided to help illustrate how to add
additional acceptance tests.  Please copy registry/should_pluginsync.rb
to additional files to create additional tests.

This patch adds an acceptance test to make sure that a registry_key
resource is created the first time puppet is run.  The test also makes
sure Puppet is idempotent by doing a second run and making sure the
created message is not in the output.

Without this patch applied the Registry module is not able to manage
both the 32 and 64 bit copies of the same-named registry subkey.

The acceptance test accompanied by this patch illustrates this failure.
Without the change to the way keys are canonically named with the path
namevar the following error message is shown:

    err: Failed to apply catalog: Cannot alias \
      Registry_key[32:HKLM\Software\Vendor\PuppetLabsTest_tYEtHVZl\SubKey1]
      to
      ["hklm\\Software\\Vendor\\PuppetLabsTest_tYEtHVZl\\SubKey1"]

This patch fixes the error by playing the 32: substring prefix in the
canonical string path returned by the path parameter munging block.

TODO: Add a spec test.

This patch adds test coverage for the following two behaviors of the
Registry_key type:

 * The purge_values => true parameter.
 * The ensure => absent parameter.

The patch implements this by running a series of Puppet agent runs with
the same Puppet Master running.  The behavior is dependent on the
FACT_PHASE facter fact set by the harness using the environment option.

Josh pointed out we repeatedly parse the path given to the
RegistryValuePath and RegistryKeyPath class instances.  This is
concerning because of the number of regular expressions we perform in
the filtering of the input path.

This patch provides a small optimization that simply stores the result
of a filter_path method call and re-uses this result on any subsequent
calls.

This is a simple fix because the only want to "set" the input path is to
instantiate a new instance of the class, passing a new path to the
initializer.

Josh pointed out that the current implementation doesn't actually use
the RegistryPathBase#default? and RegistryPathBase#valuename instance
methods.  These methods are specific to the implementation of the
RegistryKeyPath or RegistryValuePath instances.

This patch simply removes the methods from the base class and adds them
explicitly to the ancestors to make it clear where the method being
called is defined any why it's there.

Add acceptance tests for the registry type

Without this patch there is extremely limited acceptance test coverage
for the `registry_value` provider.

This patch adds a new test case which will be a comprehensive place to
test the behavior of the registry_value provider.

The test coverage provided by this patch exercises the following things:

Create registry_value resources with the following data types:

 * string (REG_SZ)
 * expand (REG_EXPAND_SZ)
 * array  (REG_MULTI_SZ)
 * dword  (REG_DWORD)
 * qword  (REG_QWORD)
 * binary (REG_BINARY)

This list is comprehensive against what the registry_value type supports
at the time of this patch.

The tests will then re-declare all of these resources used to create
these values, only using slightly different data.  This exercises the
transaction aspect of the RAL, ensuring we properly display change
methods.

At each step of create, change, we run puppet a second time and ensure
the expected create or change methods are not displayed.  This is our
assurance Puppet is idempotent and the resources were actually properly
managed to begin with.

The system should never need to call the valuename or default? methods
on a RegistryKeyPath instance.  Instead, only RegistryValuePath
instances should respond to the valuename and default? methods.

This patch simply removes the methods from the RegistryKeyPath class to
make it clear these methods are not available or meaningful when dealing
with key paths.

Add acceptance tests for registry_value provider

Without this patch the behavior of a registry_value auto requiring
parent registry_key resources does not work when the parent resources do
not share the same letter case as the value.

For example, the value fails to require the key in this scenario:

    registry_key { 'HKLM\Software\Vendor\PUPPETLABS':
      ensure => present,
    }
    registry_value { 'HKLM\Software\Vendor\puppetlabs\ValueString':
      data => "Hello World!",
    }

The root cause of this problem is that Puppet treats all resource
identifier keys as case sensitive and the registry types ascend their
`path` attribute looking up resources using the string provided by the
user in the path parameter.

This patch fixes the problem by aliasing every registry_key and
registry_value resource using the downcase version of the path
attribute.  Other resources are expected to look up related resources in
the catalog using the downcase version of the path parameter.

This solves the problem because we now have an internally consistent,
case insensitive identifier.

We preserve case for the user by not munging the case of the path
parameter itself.  Instead we simply alias the downcase version in the
catalog.

…orequire_case_sensitivity

Fix autorequire case sensitivity

Previously, running `puppet resource registry_key` or `puppet resource
registry_value` only contained documentation for the parmeters, but not
the types themselves.

Also, some of the parameter documentation lines were too long and
wrapping, but then breaking after the first word on the next line.

This commit adds documentation for the types and updates formatting
for some of the parameters.

(Maint) Add type documentation

Without this patch we don't have an easy to use way to abstract away the
management of a value and the key it's in.

This patch fixes the problem by creating a new defined resource type in
Puppet that builds on top of the native `registry_key` and
`registry_value` resource types.

This registry::value type allows the user to manage values without
worrying about also managing the key the value exists in.  For example:

    registry::value { 'MyAPP - Owner Email':
      key   => 'HKLM\Software\Puppet Labs',
      value => 'Owner Email',
      data  => 'jeff@puppetlabs.com',
    }

This resource will automatically manage the parent key if it does not
exist and manage the value.  The key and value will be created in the
native architecture of the hive.  That is to say, the 64 bit hive on a
64 bit system and the 32 bit hive on a 32 bit system.

(#14529) Add registry::value defined type