(PUP-2610) Maintain context during application exit

Because of the way rack servers get configured by puppet, the
application system needs to maintain any context information that is
setup while starting even after the application has exited. This is
because the rack app is created by calling the "master" application and
using the return value (which threads all the way back through the
application and command line layers) as the rack app. When the contexts
were removed on the way out of the application they also removed the
setup for how environments were loaded.

This also required that there be a way of undoing a series of context
pushes without knowing how many had been done. For this there is now a
mark and rollback capability in the Puppet::Context system. This is used
in the tests to always return to the context that was present at the
start of every test.
(PUP-1894) Fix issue with loading EPP from modules

The problem when loading EPP was that the name of the environment was
passed instead of the actual environment (which was expected).
This simply changes this, and adds a test that an epp can be loaded from
a module.
Merge pull request #2664 from zaphod42/issue/stable/pup-2610-rack-fails-to-track-environments

(PUP-2610) Maintain context during application exit
Merge branch 'stable'

Conflicts:
	lib/puppet/application.rb
(maint) Remove trailing commas from three env review calls

Trailing commas on hashes that are the terminal arguments in function
calls were failing when the coordinator running acceptance happened to
be using Ruby 1.8. Removed the commas.
(maint) Replace runtime logging line lost in merge of PUP-2610

This line was added for PUP-1736 and accidentally lost in the merge
churn from PUP-2610 merging up from stable. This just puts it back.
(PUP-2584) Make 404 warning on agent specific and an error.

This changes the general 404 warning issued by the indirection rest
baseclass into being an error if the option :fail_on_404 is passed
as a "query option".

This is then used when asking for a ca certificate, when asking for the
node, when asking for the initial catalog, and when retrieving a catalog
from the master.

The :fail_on_404 will raise an exception, and it is up to the caller to
determine what this means - when retrieving a catalog, there may be
retries etc. By contrast, the request for a ca certificate will fail
immediately on an agent run.

To try this, contact the master with an unknown environment when using
directory environments for the master configuration.

This more specific behavior is wanted because:
* the rest indirection is used for many different things, one of them
being probing through a list of files to use until one is found.
* the use cases where it really matters that master does not respond
with 404 should error out.
Merge pull request #2667 from hlindberg/PUP-1894-epp-in-modules

(PUP-1894) Fix issue with loading EPP from modules
Merge pull request #2669 from jpartlow/issue/master/pup-2584-make-404-warning-specific-and-an-error

(PUP-2584) Make 404 warning on agent specific and an error.
Merge remote-tracking branch 'upstream/stable'

* upstream/stable:
  (PUP-2584) Make 404 warning on agent specific and an error.
  (PUP-1894) Fix issue with loading EPP from modules

Conflicts:
	lib/puppet/configurer.rb

Resolved, merging in stable's :fail_on_404 option into the node
indirection request, and keeping master's changes to set a remote env in
the node in the likely case that locally there is no matching directory
env.
(PUP-2182) Fix yum and zypper providers virtual_package feature.

The yum and zypper package providers were installing virtual packages even when
allow_virtual was default or set to false.

For yum, the fix is to do a "yum list" command before doing an installation whenever
allow_virtual is not true.  The list command will fail on virtual
package names.  This will prevent the package from being installed as
expected and is only performed if a version is not ensured, since
virtual packages cannot be installed by version.

For zypper, the fix is to pass the --name option to zypper if not
allowing virtual packages and a version string was not ensured.
Merge pull request #2672 from peterhuene/pup/2182

(PUP-2182) Fix yum and zypper providers virtual_package feature.
(maint) Relax error match for dynmic env puppet apply test

When testing with future parser, a slightly different error message is
returned for a missing class. This patch just loosens the regex to
accept both variants.
Merge remote-tracking branch 'upstream/stable'

* upstream/stable:
  (PUP-2182) Fix yum and zypper providers virtual_package feature.
(PUP-2382) Create FFI typedefs for Win32 API

 - Add new file windows/api_types to contain global FFI typedefs
   that can be reused wherever we attach_function for FFI
 - Replace existing function definitions with new Win32 API style
   typedefs such as :dword, :lpcstr, :handle, etc
 - Fix some API definitions that were using incorrect FFI typedefs
   such as :ulong and :long.  In FFI, these typedefs are platform
   specific and will vary in size.  On Windows, these are fixed width.
   New Win32 typedefs of :win32_ulong and :win32_long were added
   to accommodate these in function definitions.
 - Fix replace_file by passing FFI::Pointer::NULL to match it's updated
   definition.
 - Where applicable, modify FFI::MemoryPointer.new to use the Win32
   typedef being created, so .new(:dword, 1) instead of .new(:uint, 1)
 - Prefix each attach_function with an ffi_lib for the dll it's
   actually loaded in.
 - Add missing documentation / links where helpful.

Paired-with: Rob Reynolds <rob@puppetlabs.com>
(PUP-2382) Standardize FFI module conventions

 - Extend FFI with attach_function_private, which allows adding an FFI
   definition to a module privately.  This is a bit simpler than nesting
   an 'API' module / clearer than FFI definitions inside a private.
 - Unfortunately this doesn't make class / struct definitions private
   but this shouldn't be an issue in a practical sense (and isn't a
   change to the previous behavior / design)
 - Refactored existing API definitions and settled on mirroring the
   Win32 names precisely.  In some modules, the API names had been
   ruby-ified, which led to collisions.  Using the casing of the Win32
   API calls is a sufficient hint to differentiate them from Ruby code.
 - Found missing values for TOKEN_INFORMATION_CLASS that were added to
   enum
(PUP-2382) FFI Puppet feature symlink test
(PUP-2382) Require windows/string earlier

 - To allow using windows/string as a mixin, require it earlier
Merge pull request #2641 from Iristyle/ticket/master/PUP-2382-standardize-FFI

(PUP-2382) Refactor Windows API FFI definitions / module conventions
(PUP-2385) Puppet::Util::Windows::File refactor

 - Use wide_string as mixin from Puppet::Util::Windows::String