[BUG] clean_env = True has inconsistent behaviour, and not what is expected

Description
When using cmd.run, clean_env has different behaviour depending on whether you specify the runas/group.

When runas is specified, clean_env only removes a minor subset of environment variables that are picked up at execution time as opposed to only passing through what has been specified by the env parameter
When runas/group is specified, most of the environment variables are re-added but changed to be that of root (SUDO_COMMAND, SUDO_GID, SUDO_UID, SUDO_USER, USERNAME).

Setup
Not sure what setup details are required.

This is being tested simply by running salt-call cmd.run.

Steps to Reproduce the behavior
Apache is just an example, specify your own login account for the full effect.

(as root)
env | wc -l 45
salt-call cmd.run 'env' <--- Reports a miriad of environment variables, 58 of them.
salt-call cmd.run 'env' clean_env=true <-- 17 have been set, LC_, pwd, etc
(as my user)
env | wc -l 33
salt-call cmd.run 'env' runas= <----- Picks up environment variables based on an interactive login shell, and a bunch more 48 Entries
salt-call cmd.run 'env' runas= clean_env=True <---- Picks up environment variables based on an interactive login shell minus a couple on my test setup. 42 Entries
salt-call cmd.run 'env' runas= group=<a valid user's group> clean_env=True <---- Picks up environment variables based on login shell. 42 Entries

Expected behavior
I would expect when clean_env=True is set, environment variables would NOT passed on from either the calling process nor picked up by checking environment variables loaded based on a login shell.

The issue appears to be in modules/cmdmod.py,
Line 464 "if runas or group", this loop will add to the env variable, that is passed in as a parameter.

As such, line 586, which checks to see if clean_env is set, and if it is set, it set's run_env = env

Suggested fix.

"if runas or group:"

Changes to
"if all((any((runas, group)), not clean_env)):"

This will then have the effect that I would expect, in that, if you specify either then runas or group AND the clean_env, it will not try and populate the environment variables based on a login session.

Versions Report

Salt Version:
           Salt: 3000.3

Dependency Versions:
           cffi: 1.14.0
       cherrypy: Not Installed
       dateutil: 2.6.1
      docker-py: Not Installed
          gitdb: 2.0.0
      gitpython: Not Installed
         Jinja2: 2.7.2
        libgit2: Not Installed
       M2Crypto: 0.35.2
           Mako: Not Installed
   msgpack-pure: Not Installed
 msgpack-python: 0.6.2
   mysql-python: Not Installed
      pycparser: 2.14
       pycrypto: Not Installed
   pycryptodome: Not Installed
         pygit2: Not Installed
         Python: 3.8.0 (default, Oct 31 2019, 18:06:22)
   python-gnupg: 0.4.6
         PyYAML: 5.3.1
          PyZMQ: 17.1.3
          smmap: 2.0.1
        timelib: Not Installed
        Tornado: 4.5.3
            ZMQ: 4.2.5

System Versions:
           dist: rhel 7.7 Maipo
         locale: utf-8
        machine: x86_64
        release: 3.10.0-1062.el7.x86_64
         system: Linux
        version: Red Hat Enterprise Linux Server 7.7 Maipo

Additional context
Add any other context about the problem here.

Start in modules/cmdmod.py around the referenced logic near lines 464 and 586, then reproduce the behavior with salt-call cmd.run env using runas, group, and clean_env. Done means clean_env prevents environment variables from being repopulated from the login environment when runas or group is specified, while preserving the existing command behavior otherwise.