(PUP-2987) Windows service runinterval parsing

 - Refactor parsing code to a separate method to cleanup run loop
(PUP-2631) Elide long URIs for 404 message

When the agent encounters a 404 response from the master and it has been
told to fail on 404, it previously output the entire path plus query
string that it requested. However, the most common case where this
occurs is when requesting a catalog, which can have a very long query
string if the request was done with a GET. This does not always occur
because even longer query strings will result in the agent using a POST
instead of a GET, which causes the long query string output problem to
go away.

In order to fix this the query string is now elided to 100 characters
(97 characters of the original text plus 3 periods).  In order to still
be able to debug any problems that might result from the query, however,
the query string is *not* elided if the log level is `debug`.
(PUP-2987) Restructure Windows service code

 - Move runinterval parsing and execution of the puppet agent to a new
   thread that maintains a busyloop until either:
    - the service is no longer running
    - an exception has occurred with parsing the runinterval
 - Rather than performing a wakeup against the main thread, simply kill
   this new thread on service_stop
 - Main service code will wait until the busyloop thread dies, then will
   exit
 - Note that this change is ultimately not responsible for the service
   hangs experienced in the service.  Additional changes have been made
   to the win32-service gem to ensure events being waited on with
   WaitForSingleObject are always signaled properly, even in failure
   cases.  Please see merged PR for more info:
   https://github.com/djberg96/win32-service/pull/21
   https://github.com/puppetlabs/puppet-win32-ruby/pull/51
(PUP-1044) Make FileBucket::File use a local file whenever possible
Changing don't to does not because grammar
(PE-4848,PUP-2999) Modified test to use puppet_tmpdir
(PE-4848,PUP-2999) Fix tempdir perms for two tests
(PE-4848,PUP-2999) Disable expected failures
(PE-4848,PUP-2999) Disable expected failure
(PE-4848,PUP-2999) Change confines to skips
(PE-4848,PUP-2999) Don't run apache external test on jvm
(PE-4848,PUP-2999) Disable test for JVM Puppet
(PE-4848,PUP-2999) Disable ticket-7117 test since has dependency on dns_alt_names CA work
(PE-4848,PUP-2999) Skipping test for now, need support for DNS Alt names in JVM puppet
(PE-4848,PUP-2999) Change puppet_tmpdir to create_tmpdir_for_user

Reflects addition of create_tmpdir_for_user to Beaker DSL.

Signed-off-by: Wayne <wayne@puppetlabs.com>
(PE-4848,PUP-2999) Ensure temporary directories ownership is correct.

`master['user']` has a default value of `root` specified in Beaker::Host::Unix.
As it turns out, this is the config option containing the username used to log
in to SUTs.

It's better then to use `on master, 'puppet master --configprint user'` since
this will always give us the actual puppet user, whether it's `puppet` or
`pe-puppet` or something else.

Also, it's best to use the `create_tmpdir_for_user` method when initially
creating temporary directories on SUTs since `host.tmpdir` will always create
directories owned by root.

Signed-off-by: Wayne <wayne@puppetlabs.com>
(PUP-2999) Re-enable tests for jvm-puppet.

Since these tests were originally disabled, fixes have been made to jvm-puppet
such that the functionality they exercise has been implemented.

Signed-off-by: Wayne <wayne@puppetlabs.com>
(PUP-1044) Add info output for when file/string is used for checksum

This commit adds Puppet.info calls to make it possible to monitor the
number of file vs string checksum computations  They can be ovserved
when running in verbose mode.
(PUP-1044) Cleanup commented out code, and comments
(PUP-3032) Add setting to always cache `feature` load attempts

This commit adds a new setting, :always_cache_features, which affects
how we cache attempts to load Puppet 'features'.  If false, then
calls to `Puppet.features.<feature>?` will always attempt to load the
feature (which can be an expensive operation) unless it has already been
loaded successfully.  This makes it possible for a single agent run to,
e.g., install a package that provides the underlying capabilities for
a feature, and then later load that feature during the same run (even if
the feature had been tested earlier and had not been available).

If this setting is set to true, then features will only be checked once,
and if they are not available, the negative result is cached and returned
for all subsequent attempts to load the feature.  This behavior is almost
always appropriate for the server, and can result in a significant performance
improvement for features that are checked frequently.