(PUP-1473) Fix issue with UTF-8 in user comments

GH-1943 included a change to munge the comment property on the user
type so that it gets encoded as ASCII-8BIT. This was to allow the comment
property to handle UTF-8 values as existing values are read as ASCII-8BIT.

Originally the change called `force_encoding` to force the encoding to
ASCII-8BIT. This method does not actually attempt to encode the string, it
only changes the string's associated encoding. It was suggested during code
review that a call to `encode` should be used instead. However, calling
`encode` will fail if the string has UTF-8 characters that cannot be
represented in ASCII-8BIT.

As we desire the comment property to be treated as a squence of bytes in
this case, we should be calling `force_encoding` instead of `encode`.
(maint) Fix spec for UTF-8 strings in user comment properties

The first problem with this spec is that it wasn't actually
being run due to an always false "if" clause.  It was checking
for `String` responding to `encode`, but `encode` is an instance
method.  `method_defined?` should have been used instead.

The second problem with this spec is that the test value did not
contain any non-ASCII characters.  If it had, it would have caught
the bug described in PUP-1473.  Added a non-ASCII character to test
for regressions.
Merge branch 'pup/1473' into stable

* pup/1473:
  (maint) Fix spec for UTF-8 strings in user comment properties
  (PUP-1473) Fix issue with UTF-8 in user comments

This closes GH-2360.
(PUP-1722) Permit HTTPS and FTP protocols in yumrepo
(packaging) Update PUPPETVERSION to 3.4.3
(PUP-897) Allow rpm package provider to query by virtual package name.

Some providers that inherit from the rpm provider, such as the yum provider, do
a query after installing a package. If the package is specified by a virtual name,
the yum provider installs the package successfully, but the base rpm provider
implementation fails to query the installed package. This causes a confusing
"could not find package" error even though the package was installed.

Passing the '--whatprovides' option to rpm when performing a query instructs rpm
to locate packages that provide the given virtual name. This enables child providers
to install by virtual package name without errors.
Merge pull request #2370 from peterhuene/master

(PUP-897) Allow rpm package provider to query by virtual package name.
(PUP-652) Fix error reporting for ParsedFile

Puppet::Error may not have a setter for file, so check if there is
one first (like ExternalFileError has).

This was previously tracked in redmine as #19422
(PUP-1584) Expand some modulepath settings for windows

A couple of module_tool specs modified for PUP-1584 were not being
expanded such that they would work properly on Windows or POSIX.
Merge pull request #2363 from domcleal/tickets/master/pup-1722-yumrepo-protocols

(PUP-1722) Permit HTTPS and FTP protocols in yumrepo
Merge branch 'issue/master/pup-1584-expand-path-for-specs-on-windows'

* issue/master/pup-1584-expand-path-for-specs-on-windows:
  (PUP-1584) Expand some modulepath settings for windows
Merge branch 'pr/2026'

* pr/2026:
  (PUP-652) Fix error reporting for ParsedFile

Closes GH-2026
Merge tag '3.4.3'

3.4.3

* tag '3.4.3':
  (packaging) Update PUPPETVERSION to 3.4.3
  (maint) Fix spec for UTF-8 strings in user comment properties
  (PUP-1473) Fix issue with UTF-8 in user comments
(PUP-1676) Puppet::Settings retrieves directory environment settings

During a Puppet[:setting] call, legacy environment settings would be
loaded from a puppet.conf stanza.  But settings from directory
environments would never be seen.  Areas in the codebase could obtain
per environment settings by looking them up directly from an
environment.  However a call to puppet config or to an application with
--configprint, would return the default modulepath if redirected to a
directory environment using the --environment setting.

A ValuesFromCurrentEnvironment class has been added to Settings to
lookup environment settings not found in puppet.conf if there is a match
with the :current_environment from the Context.

Because of the need to access a global modulepath for environment and
directory loader construction, a setting, :basemodulepath, has been
added, so that we can initialize without fear of recursing infinitely
looking up :modulepath.

The possibility for recursion has been there since at least 3.0.0:

[legacy]
modulepath=/foo:$modulepath

would overflow the stack. It could now be:

[legacy]
modulepath=/foo:$basemodulepath
Merge pull request #2369 from jpartlow/issue/master/pup-1676-puppet-config-print-and-direnvs

(PUP-1676) Puppet::Settings retrieves diectory environment settings
(PUP-1677) Fix tests for PE compatibility

1) A SLES compatibility issue was fixed

2) the reset_agent_ssl helper does not work on PE. A test which relied
on it would fail because it used duplicate certificate names. That
test was updated to use unique certificate names for each cert
request, to avoid duplicate cert issues.
Merge pull request #2371 from branan/fixup_tests_for_pe

(PUP-1677) Fix tests for PE compatibility
Merge remote-tracking branch 'upstream/stable'

* upstream/stable:
  (PUP-1677) Fix tests for PE compatibility
(pup-1732) Report only services from systemd

Prior to this change the systemd service provider would return
all systemd-managed types (including sockets, devices, swap, etc).
This produced a huge list of instances, many of which were not
in fact services.

This change simply adds the '--type service' option to the
'systemctl' invocation in .instances. It also updates the
spec tests with fixtures for the old (without that option)
and new (with that option) way of invoking 'systemctl'.

I purposefully did not touch the existing fixture which is
tied to a test which is pending on a what-to-do about failed
services. If/when we tackle that, we may want to collapse
some of these fixtures.