Update remote_ssh_cmd to optionally return output on success

We go back and forth on this, but I've finally found a usecase for wanting the
stdout from a remote ssh command. Reprepro won't return non-zero when it
ignores a deb for inclusion in a repo. With the promotion process, we've been
assuming that just checking for an equivalent package in packages.json is a
safe check for preventing duplicate package promotions. However, as we've found
with trying to get a new PE version pipeline in order, we can't always rely on
packages.json to be accurate. When it's not, we've been "successfully"
promoting packages, when in fact the debs are completely ignored by reprepro
because they already exist in the debian repos. The metadata in packages.json
is still updated though, which leads to failed composes because the md5s don't
match up between packages.json (has the ignored deb md5) and the real package
in the repo (has the pre-existing deb md5).

This commit modifies the remote_ssh_cmd method to use the open3.capture3 method
for executing system calls. This method returns the stdout, stderr, and exit
status object for a given system call. We use it to get the output, and exit
status, of our ssh command. To return this output, callers of this method add
"true" for verbose to the invocation. This will only happen on success -
failure will still raise an exception. This is backwards compatible.

Signed-off-by: Moses Mendoza <moses@puppetlabs.com>
Update reprepro invocation to capture output

This commit leverages the previous commit's new facility in remote_ssh_cmd for
capturing the output of an ssh command. We do so to scan the output for
"Skipping Inclusion" - a string that indicates reprepro has refused to add a
deb to the repository because one of the same NVR already exists. When reprepro
does this, it exits 0. We were previously not handling this case, assuming
success based on the exit code. If reprepro has skipped inclusion, we now fail,
as we should.

Signed-off-by: Moses Mendoza <moses@puppetlabs.com>
Merge pull request #360 from melissaanne/master

(maint) For security release, email puppet-security-announce
Merge pull request #358 from MosesMendoza/maint/master/stricter_deb_shipping

Maint/master/stricter deb shipping
Use name as defined in ext/project_data.yaml rather than that provided by JIRA

This variable is defined for all projects. This will not change much,
except for where we have multiple projects under one JIRA project.
MCollective plugins is the prime example here. We have multiple plugins,
all with different names, but work is tracked under a single JIRA
project (MCOP). Because of this, the mcollective plugins, regardless of
which plugin is going to be released, all are assigned the same release
ticket title. This way, we can ensure the ticket title will be more
project specific, regardless of JIRA project.

It will not be as nice, for instance, when doing a Razor release, we
currently have `Razor 0.16.0 2014-11-24 Release`, but this will change
to `razor-server 0.16.0 2014-11-24 Release`.