Work around Lmod bug in KDE update packages, with new mechanism

It seems like the situation where we need to pull an update from
updates-testing into all update tests to work around some known
issue is going to keep happening. So instead of constantly
adding and then entirely removing bespoke lines for each specific
workaround, let's have a permanent mechanism for doing this: a
hash with release numbers as keys, and arrayrefs of update IDs
as values, and a block to call `bodhi updates download` on the
appropriate array for the release under test. This way, to add
or remove a workaround you just update the hash. If we're at a
point where *no* workarounds are needed the %workarounds hash
can be made entirely empty (it must exist, though) and the code
will be a clean no-op.

The actual workaround here pulls in Lmod updates I just sent out
to work around this issue in one of the KDE update tests:

https://openqa.fedoraproject.org/tests/497160#step/base_update_cli/11

there's some code in Lmod that gets sourced in bash profiles
which breaks openQA's `validate_script_output` by blurping two
lines of informational output into the output of the script.
The update backports a change from upstream Lmod master that
sends that informational output to stderr instead of stdout.

Signed-off-by: Adam Williamson <awilliam@redhat.com>

lib/utils.pm

@@ -437,6 +437,7 @@ sub _repo_setup_updates {
     # Appropriate repo setup steps for testing a Bodhi update
     # Check if we already ran, bail if so
     return unless script_run "test -f /etc/yum.repos.d/advisory.repo";
+    my $version = get_var("VERSION");
     repos_mirrorlist();
     if (get_var("DEVELOPMENT")) {
         # Disable updates-testing so other bad updates don't break us
@@ -504,13 +505,30 @@ sub _repo_setup_updates {
     assert_script_run 'rpm -qp *.rpm --qf "%{NAME} " > /var/log/updatepkgnames.txt';
     upload_logs "/var/log/updatepkgnames.txt";
 
+    # we periodically need to pull an update from updates-testing in
+    # to fix some bug or other. so, here's an organized way to do it.
+    # we do this here so the workaround packages are in the repo data
+    # but *not* in the package lists generated above (those should
+    # only include packages from the update under test). we'll define
+    # a hash of releases and update IDs. if no workarounds are needed
+    # for any release, the hash can be empty and this will do nothing
+    my %workarounds = (
+        "30" => ['FEDORA-2019-9ff3036c0a'],
+        "31" => ['FEDORA-2019-6f121fa8a0']
+    );
+    # then we'll download each update for our release:
+    my $advisories = $workarounds{$version};
+    foreach my $advisory (@$advisories) {
+        assert_script_run "bodhi updates download --updateid=$advisory", 180;
+    }
+
     # create the repo metadata
     assert_script_run "createrepo .";
     # write a repo config file, unless this is the support_server test
     # and it is running on a different release than the update is for
     # (in this case we need the repo to exist but do not want to use
     # it on the actual support_server system)
-    unless (get_var("TEST") eq "support_server" && get_var("VERSION") ne get_var("CURRREL")) {
+    unless (get_var("TEST") eq "support_server" && $version ne get_var("CURRREL")) {
         assert_script_run 'printf "[advisory]\nname=Advisory repo\nbaseurl=file:///opt/update_repo\nenabled=1\nmetadata_expire=3600\ngpgcheck=0" > /etc/yum.repos.d/advisory.repo';
         # run an update now (except for upgrade tests)
         script_run "dnf -y update", 900 unless (get_var("UPGRADE"));