Update the Beaker version to use "2.20" which has an important fix for PE
installations.

(MODULES-2452) Update Beaker Version

* stable:

* stable:
  (maint) add release date
  (FM-3477) Release 1.0.6

(maint) update modulesync files

We don't use DevKit in CI, so it should not be required for
normal testing purposes.

(maint) update modsync / fix build

…d_docs

Mention that templates need to have DOS linefeeds

Add acceptance tests for PowerShell single session support. Also, I found
some small typos that I fixed as well.
[skip-ci]

Added tests for environment variable leaking to address feedback.

…_session_acceptance

(MODULES-3011) Acceptance Test for Single Session

Running gem install bundler on appveyor is redundant because it is already present.
Removing it will speed up build times

…move-gem-install-bundler

(FM-4881) Remove gem install bundler on Appveyor

 - Rake 11 was recently released with an incompatible change for
   versions of rspec-core < 3.4.4 (released / fixed 3/9/2016). The
   current Gemfile pessimistically versions against rspec 3.0.0, but
   that prevents it from installing a newer version that would require
   the appropriate / compatible version of rspec-core.  Without this
   change rspec-core 3.0.4 gets installed, which prevents rake from
   running.

   Without the change, any fresh bundles across various OSes, including
   CI in TravisCI and AppVeyor will fail to run any rake tasks.

   An alternate solution would limit rake to < 11, but in testing this
   seemed just as valid.

…mpatibility

(maint) Changed allowed rspec version

Copy paste of improvements done the in the Puppet DSC module for using
PowerShell.

Adjust appveyor to run integration tests as well as unit tests

 - Modernize metadata.json by removing support for Windows 2003

   Also note that since the new PowerShellManager class requires FFI,
   there is an implied restriction on being able to use the newer
   performance improved code paths, even though metadata.json does
   not reflect this.

 - This will allow the class to be required on all platforms, even
   where it is not used.

 - Previously, producing PowerShell code was inlined into the
   PowerShellManager class. Move this out to a separate template in
   preparation of major modifications.

 - The current PowerShellManager class had some dependencies on
   certain Puppet class layout.  Rework the FFI code to remove the
   class hierarchy dependency, and to not rely on the api_types.rb
   helper found in Puppet 3.7+.  Instead, use all native FFI type
   names and add local definitions for CloseHandle and
   WaitForSingleObject.

 - This is a simple method that can be used to determine whether or
   not PowerShellManager can be used.  This essentially boils down to
   2 things:

   - On Windows
   - win32console gem is not loaded (used on Puppet 3.x / Ruby 1.9.3)
     win32console gem breaks stdout/stderr/stdin redirection

Port of the PowerShell session code from the DSC module. This code
includes some significant speed and system utilization improvements.
In the prior version every call to exec started a brand new PowerShell
process for each of the exec modes: command, onlyif and unless. This
was costly in both time and system resources as PowerShell takes
significant time to intialize and frequent process creations spike CPU
on the target system.

In this version, a single PowerShell process is created that lives not
only for all the modes of exec, but also for the entirety of the
Puppet run. We still have a one time cost of time and system
utilization for process creation for the entire run, but gain the
ability to run consecutive commands.

A second improvement to this version is that we directly pass commands
to PowerShell through shell redirection, and not through reading a
file in like the last version. This avoids any of the parsing errors
(MODULES-2634) we have seen. This also improves syntax checking, as we
now validate the passed in commands using PowerShell itself before the
command is run, allowing us to catch errors sooner and report them.

 - Previously, on PowerShell instances where the ResetRunspaceState
   method is not available (PS < 3), variable state is not reset
   between invocations and can run over from one session to the next.

   This is bad because it could cause side effects or prevent other
   security issues.  Remedy that situation by capturing session state
   on initial run, and resetting it back to initial state manually
   before each user invocation.

 - Previously, regardless of the PowerShell version, environment
   variables could bleed over from one run to the next.

   This is bad because it could cause side effects or prevent other
   security issues.  Remedy that situation by capturing the initial
   environment and isolating process specific environment variables.

   On each new invocation, recapture the Machine and User environment
   variables from the registry (using .NET APIs) and layer the
   process environment variables on top of that to effectively reset
   the environment.  This preserves previous behavior that would have
   been observed by creating a new PowerShell.exe instance per block
   of user code to execute.

We were previously testing that this module handled exceptions
correctly by using 'Write-Error'. This worked incidently, but was not
technically correct. 'Write-Error' is a non-terminating error which
does not equate to a non-zero exit code. However, if it is the only
command sent to the PowerShell console, the PowerWhell host reports it
as a non-zero exit code. If something is added after 'Write-Error',
then a zero exit code is returned.

This can be seen in the following example:

PS C:\vagrant> powershell -command "write-error foo"
write-error foo : foo
    + CategoryInfo          : NotSpecified: (:) [Write-Error],
    WriteErrorException
        + FullyQualifiedErrorId :
        Microsoft.PowerShell.Commands.WriteErrorException
PS C:\vagrant> $LASTEXITCODE
1
PS C:\vagrant> powershell -command "write-error foo;ls"
write-error foo;ls : foo
    + CategoryInfo          : NotSpecified: (:) [Write-Error],
    WriteErrorException
        + FullyQualifiedErrorId :
        Microsoft.PowerShell.Commands.WriteErrorException

            Directory: C:\vagrant

Mode                LastWriteTime     Length Name
....
PS C:\vagrant> $LASTEXITCODE
0

The fix for this is to use 'throw' when we are testing that this module
can return a non-zero exit code.

(MODULES-2962) Reuse PowerShell Session

  - In a4cd1f5, an effort was made
    to ensure that the code in PowerShellManager that consumed FFI was
    written in a Puppet version agnostic way.

    Unfortunately, two additional items were incorrect:

    * :handle was aliased to uintptr_t
    * FFI functions are declared with attach_function_private which is
      not part of FFI.  Rewrite the code to not require the
      api_types.rb helper attach_function_private from Puppet 3.7+

(maint) Fix private FFI declarations

Beaker needs a version of Rake less than
11 due to using `last_comment' in
rake_task.rb:62. Reduce the version of Rake
down to the same dependency that Beaker does
as a development dependency.

Paired with Glenn Sarti <glenn.sarti at puppetlabs dot com>

…ilds

(FM-4952) Restrict Rake to ~> 10.1

Due to the changes from MODULES-2962, ticket MODULES-2634 is fixed
as a side effect. Besides the module itself using try/catch semantics
in a templated PS1 file, it supports any kind of syntax or formatting..

This commit adds two tests to ensure that this is the case. One for
integration testing, the other for acceptance.

…tch-tests

(MODULES-2634) Test try/catch in PowerShell provider

When the function to reset the Environment Variables for the single
session PowerShell process was added, the Verbose paramater was mistakenly
left on the Remove-Item and Set-Item cmdlets. This causes a Verbose
message to be written every time the provider is executed, polluting the
Puppet Debug stream. This is only an issue when MODULES-3137 is
implemented as it enables logging Verbose statements.

This removes the Verbose parameters.

…-verbose-env-variable-setting

(MODULES-3280) Remove Verbose Environment Variable Handling

Prior to this, the README had examples of containing multi-line or
complex PowerShell scripts to be `exec`'d as templates. The examples
shown weren't actually templates and didn't have any ERB code in them.
This led to some confusion on first glance because the PowerShell code
shown didn't have any dynamic code in it; it was static code. It also
could lead some users to believe that the template() function is required.

This commit fixes that by converting the examples shown to using the
file() function and static files. It also leaves a note that actual
templates can be used if the PowerShell scripts do in fact need to be
dynamic or access Puppet variables.

This commit cleans up the following in the README:

* errant whitespace
* Puppet code indentation
* syntax highlighting for Puppet and PowerShell examples

This commit reverts the changes introduced in PR #84 (6ed1d95). These tests
failed in CI and prevented further testing.  This PR will probably be
superceded by MODULES-3285 in the future.

Revert "(MODULES-2634) Test try/catch in PowerShell provider"

{WIP}(FM-4639) Release 2.0.0

(MODULES-3192) Use file() instead of template() in the README

(maint) modsync update - stable

* stable:
  (maint) modsync update

Merge stable to master