(Bug #22237) Remove EOL Fedora 17

Since Fedora 17 is now EOL, it's time to remove it from our mock list
Merge pull request #1844 from melissaanne/maint/stable/re-141_rm-eol-f17

(Bug #22237) Remove EOL Fedora 17
(#19056) strip trailing space while parsing AIX password file
Merge pull request #1763 from djmitche/bug19056

(#19056) strip trailing space while parsing AIX password file
(#22358) Interpret */* as anything is accepted

The changes to how we process Accept headers left out the case of being
asked for anything (*/*), which the puppet dashboard will do. This
expands */* to mean the client accepts any format the the requested
endpoint can support.

In addition, this also adds logic to ignore quality specifiers.
Merge pull request #1863 from zaphod42/issue/stable/22358-improper-handling-of-accept-headers

(#22358) Interpret */* as anything is accepted
(#22375) Prefer raw-like serialization format

Previously, agents would backup files using PSON serialization, which is
not reliable for binary content, and incredibly inefficient due to the
applying a regexp to the entire in-memory file content.

Ideally, I would like to switch the Puppet::FileBucket::File class to
just use the `:raw` serialization format as is done for
Puppet::FileServing::Content. But this cannot be done in a minor series
without breaking compatibility between newer 3.x agents talking to older
3.x masters.

However, we can achieve the same effect by using the `:s` serialization
format, and we don't have the same compatibility problem because
the `from_s` method has been defined since 2.6.0 in commit e5a78009f.

If a newer master receives a file bucket request from an older agent
that sends a PSON encoded file, then the master will generate a
deprecation warning to update the agent.

Originally filed as #8229.
(#22375) Don't echo the backed up file to the caller

Previously, when the agent backed up a file to the master, the master
would inadvertently echo the file back to the agent in the body of the
HTTP response.

This is because the terminus' save method returned the file contents
as the 'result', and when invoked via REST, the {webrick,rack} REST
handlers automatically write the result into the response body.

Also puppet masters prior to 3.3 did not respect the Accept HTTP
header (#21427), so the master would always YAML encode the response,
which for binary content, large files, etc could result errors like
the following on the master:

    Error: Stack overflow in regexp matcher: /\A(?: # ?: non-capturing group (grouping with no back references)
                 [\x09\x0A\x0D\x20-\x7E]            # ASCII
               | [\xC2-\xDF][\x80-\xBF]             # non-overlong 2-byte
               |  \xE0[\xA0-\xBF][\x80-\xBF]        # excluding overlongs
               | [\xE1-\xEC\xEE\xEF][\x80-\xBF]{2}  # straight 3-byte
               |  \xED[\x80-\x9F][\x80-\xBF]        # excluding surrogates
               |  \xF0[\x90-\xBF][\x80-\xBF]{2}     # planes 1-3
               | [\xF1-\xF3][\x80-\xBF]{3}          # planes 4-15
               |  \xF4[\x80-\x8F][\x80-\xBF]{2}     # plane 16
               )*\z/mxn

This commit changes the Puppet::FileBucketFile::File terminus to
return a new model instance whose content is empty. This is a change
from previously when we were returning a string, but I think it's
clearer that the result needs to be serializable using one of the
Accept content-types that the client specified, e.g. `:s`.

Originally filed as #8229
(#21427) Make report format selectable

Without making agents able to select the format to serialize reports, a
newer agent would be unable to submit reports to an older master.
Although we ask users to upgrade masters first, that is not often done
in practice. In order to allow those kinds of setups to work, this makes
the report format selectable.

Puppet 3.2.2 and later support reports as pson, so only older, insecure
masters need to have the agent's change this new setting.
(#21427) Handle loss of precision during YAML serialization

Previously, when round-tripping a report using YAML, the
Puppet::Resource::Status#time object could lose precision (depending on
the ruby version and platform), so it did not match the expected value. For
example, the expected value was:

    "time"=>"2013-09-04T17:01:38.510604415+00:00"

But the round-tripped value was:

    "time"=>"2013-09-04T17:01:38.510604000+00:00"

This commit changes the test to explicitly compare status fields, and
handles the `time` field specially to avoid loss of precision during
YAML serialization.
Merge branch 'issue/stable/21427-select-report-serialization-format' into stable

* issue/stable/21427-select-report-serialization-format:
  (#21427) Handle loss of precision during YAML serialization
  (#21427) Make report format selectable
(#21427) make supported_formats return an array of symbols

Prior to this commit, supported_formats was returning an array of
strings, which violated the contract for FormatHandler's
most_suitable_format_for method.  This commit fixes supported_formats
to return an array of symbols.
Merge pull request #1874 from kylog/issue/21427-fixup

(#21427) make supported_formats return an array of symbols
Docs: Clarify descriptions of "ordering" and "report_serialization_format" settings
Merge pull request #1870 from joshcooper/ticket/stable/22375-filebucket-serialization

(#22375) File bucket serialization
Merge pull request #1876 from nfagerlund/330-setting-descriptions

Docs: Clarify descriptions of "ordering" and "report_serialization_format" settings
(#22258) Create new console for each puppet run

Powershell apparently has some issue trying to share the Windows
service's console when running under ruby.exe (as opposed to rubyw.exe).
This patch causes the service to create a new console for each puppet
child it kicks off, which resolves the issue.
Merge branch 'ticket/stable/22258-create-new-console' into stable

* ticket/stable/22258-create-new-console:
  (#22258) Create new console for each puppet run
(#22383) Allow all boolean values for atboot

The previous restrictions placed on the atboot property for mount caused
some previously valid manifests to begin to fail. The problem stems from
the fact that atboot is only used on solaris, but can always be
specified by users. It used to be able to be nearly anything, but only
yes and no meant anything on solaris. This fixes the problem by
expanding the allowed values to include all of the "boolean" values as
expressed in the Puppet::[Parameter|Property]::Boolean type and using a
munge method to convert the boolean to the correct yes or no value.
Merge pull request #1879 from zaphod42/issue/stable/22383-mount-no-longer-allows-true-for-atboot

(#22383) Allow all boolean values for atboot