…port

(MODULES-10987) Add Fedora 32 to puppet_agent module

This removes the puppet5 collection from the list of available sources
for the puppet agent install task, since it's EOL. This also
updates the task spec to use puppet6 for testing and only test upgrading
from puppet 6 to puppet 7, not puppet 5 to puppet 6.

(MODULES-10989) Remove puppet5 collection

Starting with puppet 6.22.0, `puppet facts diff` supports a new parameter
`--exclude` that allows users to remove certain facts from output

This commit exposes `puppet facts diff` `--exclude` parameter to
`facts_diff` task via `exclude` parameter

Do not pass thru empty string value for `exclude` parameter of
`facts_diff` task since `puppet facts diff` will show no facts
difference (PUP-11028)

Before this commit, even if `puppet facts diff` command fails it is shown
as successful run by bolt. Now if the command fails, the exception will be shown:
```
Started on my_target...
Failed on my_target:
  The task failed with exit code 1 and no stdout, but stderr contained:
  /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util/execution.rb:297:in `execute': Execution of '/opt/puppetlabs/bin/puppet facts diff --exclude 123' returned 1:  (Puppet::ExecutionFailure)
  	from /tmp/fc20f3c9-9e66-45b4-bc40-d7780332cbd5/puppet_agent/tasks/facts_diff.rb:42:in `run'
  	from /tmp/fc20f3c9-9e66-45b4-bc40-d7780332cbd5/puppet_agent/tasks/facts_diff.rb:64:in `<main>'                                                                Failed on 1 target: my_target
Ran on 1 target in 2.4 sec

```

The command output check was also updated, since starting with puppet 6.22.0
the json output is pretty

…am-to-fact-diff

win32-dir seg faults on ruby 2.5.9
```
C:/hostedtoolcache/windows/Ruby/2.5.9/x64/lib/ruby/gems/2.5.0/gems/win32-dir-0.4.9/lib/win32/dir.rb:89: [BUG] Segmentation fault
ruby 2.5.9p229 (2021-04-05 revision 67939) [x64-mingw32]

-- Control frame information -----------------------------------------------
c:0042 p:---- s:0186 e:000185 CFUNC  :SHGetFileInfo
```

(maint) lock to ruby 2.5.8 to avoid segmentation fault

This adds a task that removes the local filebucket
which was disabled by default in Puppet 7.
The location of filebucket is determine using the
`clientbucketdir` puppet config.

```
❯ bolt task show puppet_agent::delete_local_filebucket
puppet_agent::delete_local_filebucket
  Removes the local filebucket

Usage
  bolt task run puppet_agent::delete_local_filebucket --targets <targets>
  [force=<value>]

Parameters
  force  Optional[Boolean]
    ignore nonexistent files and errors
```

SLES 11 can no longer be upgraded in PE by installing from the repos. To
work around this, if we're SLES 11 and PE, download the package and
install it directly using rpm, regardless of the value of `manage_repo`.
This is the same approach we take for AIX, macOS and Windows. Because
zypper is left in a semi-broken state if our pe_repo is installed, make
sure we remove it and don't install it again.

The GPG keys will continue to be imported.

For non-PE agents, installing from the FOSS repos should still be
possible, so nothing should change on that part. Additional tests were
added to assert the behavior of FOSS vs PE.

The install class was getting a bit complex, so I pulled out the SUSE
logic into a separate file.

This also made it easier to add a GPG check before installing the RPM
file. Since we don't use zypper anymore on SLES 11 in PE, create a
separate `exec` resource to handle the GPG check before upgrading.

The puppet GPG signing key with ID 4528b6cd9e61ef26 had a subkey in it
until February 2021. This caused GPG checks on systems with RPM versions
that do not support subkeys[1] (SLES 11 and EL 5) to fail.

We added this GPG key in the puppet_agent module in January, and
included it in the 4.4.0 release of the module.

We discovered the subkey issue in February and promptly removed the
subkey from the existing key. The new key is available since version
4.5.0 of the puppet_agent module.

This module imports GPG keys based on their ID. Since in our case both
the good key and the bad key have the same ID, the module will not
import the correct key if the bad one is already installed (or any other
key with the same ID for that matter).

To circumvent this, we now specifically compare the contents of the GPG
key from the RPM database with the contents of the GPG key laid by
Puppet in `/etc/pki/rpm-gpg`. If any differences are found, the imported
key is purged and reimported, which should ensure that the key shipped
in the module is identical to the from the RPM database.

[1] https://technosorcery.net/blog/2010/10/pitfalls-with-rpm-and-gpg/

By relying on the puppet service to upgrade puppet we lose all logging
info in case something fails, which makes things difficult to debug.
Change to run with puppet agent -t.

We can also fix the logging part by configuring puppet to log to a file,
then printing the contents of the file.

(MODULES-11048) task to remove local filebucket

(MODULES-10996) Fix SLES 11 PE upgrades

(maint) update tasks documentation

We still want puppet5 users who need to upgrade to puppet6 to be able to
use the latest puppet_agent module. Even though the required puppet
version in metadata.json is not enforced when installing the module, it
still shows up on the Forge and can cause confusions as to whether the
module can be used on puppet5 or not.

The bug fixes and improvements that we do in the module still benefit
puppet5 and we should encourage users to always use the latest version
of the module.

This commit updates metadata.json to show puppet5 support.

(MODULES-11046) Release prep for 4.6.0