salt.modules.zypperpkg.install does return sufficient message for error reasons

[tash]

Description of Issue

The error information for installing a RPM package through zypper is not complete, which leads to an incomplete salt result message. There is no workaround as several error messages are provided as stdout by zypper in non-interactive-mode instead of stderr. Zypper also does not log the attempt in the example below (/var/log/zypp/history), leaving no indication of the reason.

So the following call will produce the observed result with no indication of what went wrong:
salt target pkg.install testpackage
Let's assume testpackage requires package/capability "my-requires-package".
Observed Behaviour

test:
    ERROR: Zypper command failure: Running scope as unit: run-r8cb1ce82cd4a40a39269bcb54d1b26b2.scope
ERROR: Minions returned with non-zero exit code

Expected Behaviour

test:
    ERROR: Zypper command failure: Running scope as unit: run-r8cb1ce82cd4a40a39269bcb54d1b26b2.scope
    Loading repository data...
    Reading installed packages...
    Resolving package dependencies...

    Problem: nothing provides my-requires-package needed by testpackage
     Solution 1: do not install testpackage
     Solution 2: break testpackage by ignoring some of its dependencies

    Choose from above solutions by number or cancel [1/2/c/d/?] (c): c
ERROR: Minions returned with non-zero exit code

Cause
_Zypper._check_result only checks for stderr when not in xml-mode:

salt/salt/modules/zypperpkg.py

Line 254 in 8d4d5ea

msg = self.__call_result['stderr'] and self.__call_result['stderr'].strip() or ""

Instead, it should check for stdout as well. One possible solution could be the following snippet producing the expected result (above):

msg = (self.__call_result['stderr'] and self.__call_result['stderr'].strip()) + "\n" + (self.__call_result['stdout'] and self.__call_result['stdout'].strip()) or ""

Setup

salt-minion on testhost (s. below)

Steps to Reproduce Issue

salt target pkg.install my-rpm-package-that-zypper-will-not-be-able-to-find-a-provider-for

Versions Report

Note that openSUSE 15.1 maintains the package as 2019.2.0 but for whatever reason already contains zypperpkg.py instead of the old zypper.py module => different /patched version.

Salt Version:
           Salt: 2019.2.0

Dependency Versions:
           cffi: Not Installed
       cherrypy: Not Installed
       dateutil: Not Installed
      docker-py: Not Installed
          gitdb: Not Installed
      gitpython: Not Installed
          ioflo: Not Installed
         Jinja2: 2.10.1
        libgit2: Not Installed
        libnacl: Not Installed
       M2Crypto: Not Installed
           Mako: Not Installed
   msgpack-pure: Not Installed
 msgpack-python: 0.5.6
   mysql-python: Not Installed
      pycparser: Not Installed
       pycrypto: 2.6.1
   pycryptodome: Not Installed
         pygit2: Not Installed
         Python: 3.6.10 (default, Jan 16 2020, 09:12:04) [GCC]
   python-gnupg: Not Installed
         PyYAML: 3.13
          PyZMQ: 17.0.0
           RAET: Not Installed
          smmap: Not Installed
        timelib: Not Installed
        Tornado: 4.5.3
            ZMQ: 4.2.3

System Versions:
           dist:
         locale: UTF-8
        machine: x86_64
        release: 4.12.14-lp151.28.36-default
         system: Linux
        version: Not Installed

Host

   Static hostname: n/a
Transient hostname: testhost
         Icon name: computer-vm
           Chassis: vm
        Machine ID: ---
           Boot ID: --
    Virtualization: kvm
  Operating System: openSUSE Leap 15.1
       CPE OS Name: cpe:/o:opensuse:leap:15.1
            Kernel: Linux 4.12.14-lp151.28.36-default
      Architecture: x86-64