[BUG] Avoid saltenv:dev, saltenv:prod from being dynamically redefined.

Description
For each minion via configuration files /etc/salt/minion and/or /etc/salt/minion.d/env.conf are defined 'saltenv:dev' versus 'saltenv:prod'. Have a system environment where dev and prod minions are utilized from same salt-master. Goal is to not permit these definitions to be dynamically redefined, but hard coded in associated configuration files

Can't have all environments in file_roots: definition on salt-master (e.g., /etc/salt/master) as will select first valid reference. If not in base, can't execute without specifying saltenv.

Concerned administrators may accidentally reference an INCORRECT environment when having to do manually via saltutil.sync_modules updates (e.g., saltenv=prod). Should ONLY USE the "hardcoded" values in above configuration files, where any saltutil.sync* calls SHOULD NOT NEED TO INDICATE saltenv (as is already defined in above configuration files) and SHOULD NEVER BE REDEFINED.

• Don't want to have to qualify minions with different glob or qualifiers (e.g., -E, -G) for same manual entry errors.
• Worst-case mitigation: will have to force "saltenv form configuration files" definitions via python coding layer(s)

Setup

Example:

• file_roots: definition used:

file_roots:
 base:
   - /srv/salt/base
 dev:
   - /srv/salt/dev
 prod:
   - /srv/salt/prod

Using _modules python scripting.

A desired scenario is executed via python on minion using saltenv:dev already defined in minion configuration. **SHOULD NOT NEED TO SPECIFY saltenv=dev on command line:
$ salt <minion_with_correct_saltenv_dev> s.test

Contents of s.test.py for minion with saltenv: dev in /etc/salt/minion :
def test():
return "**from a dev minion"

Should not be able to execute below, even with dynamic saltenv=prod in command.

$ salt <minion_with_saltenv_prod> s.test
Contents of s.test for minion with saltenv:prod in /etc/salt/minion:
def test():
return "**from a prod minion"

Please be as specific as possible and give set-up details.

• on-prem machine
• [X ] VM (Virtualbox, KVM, etc. please specify)
• VM running on a cloud service, please be explicit and add details
• container (Kubernetes, Docker, containerd, etc. please specify)
• or a combination, please be explicit
• jails if it is FreeBSD
• classic packaging
• onedir packaging
• used bootstrap to install

Steps to Reproduce the behavior
Referenced in Setup

Expected behavior
Referenced in Setup

Versions Report
Only provided salt version # from salt--versions-report

Salt: 3003.4

Start by reviewing how saltenv is read from /etc/salt/minion and /etc/salt/minion.d/env.conf, then trace the _modules and saltutil.sync* paths involved in the example commands. Done should mean that a minion's configured saltenv cannot be dynamically overridden, and sync calls do not need to specify saltenv.