Fixes #527.

`environment` is being deprecated, renamed to `saltenv`

Don't add key_url as it is deprecated and not needed when
pkgrepo_keyring is set. This has been supported since stretch so make it
the default. Also use py3 repo by default for Debian family as it is now
the only option.

Additionally, Raspbian has been updated to use signed-by by default.

Fixes #520

Ensure extra options in generated configuration is sorted, to ensure stable
configuration.

When option was specified, it appeared twice in config, making configuration
file buggy, and not loaded.

Also:

* add keyring file for the salt repo, due to `apt-key` deprecation
* remove old repository file

Having it set as true causes an error with the minion config when the salt-minion starts

Avoid this error:

```
      ID: salt-master
Function: pkg.installed
  Result: False
 Comment: Error occurred installing package(s). Additional info follows:

   errors:
       - Running scope as unit run-402.scope.
         Loaded plugins: ovl, ulninfo
         https://repo.saltproject.io/py3/redhat/7Server/x86_64/3002/repodata/repomd.xml:
             [Errno 14] HTTPS Error 404 - Not Found
         Trying other mirror.
         No package salt-master available.
         Error: Nothing to do
```

Use the following command:

```
$ GREP_SED="\(repo\.salt\)stack\.com" \
  && grep -rl --exclude-dir=.git "${GREP_SED}" \
  | grep -v .un~$ \
  | xargs sed -i -e "/${GREP_SED}/s//\1project.io/g"
```

Use the `retry_options` already being used for the Salt minion service,
since we're getting failures such as this one:

* https://github.com/myii/salt-formula/runs/2415072504

This is made worse by the fact that GitHub Actions cannot re-run a
single job (at the current time).

Right now when you set module_config entries in your pillar data
like this:
salt:
  minion:
    module_config:
      smtp.from: 'Kali Salt <admins+salt@kali.org>'
      smtp.to: 'Kali Admins <admins+salt@kali.org>'
      smtp.host: localhost
      smtp.subject: 'Results of salt actions on'
      smtp.fields: id,fun

On each run, you will always a different ordering of the various
fields in the minion configuration file, leading to spurious restart
of the minion and admin annoyance:

          ID: salt-minion
    Function: file.recurse
        Name: /etc/salt/minion.d
      Result: True
     Comment: Recursively updated /etc/salt/minion.d
     Started: 13:39:25.689775
    Duration: 874.318 ms
     Changes:
              ----------
              /etc/salt/minion.d/f_defaults.conf:
                  ----------
                  diff:
                      ---
                      +++
                      @@ -930,10 +930,10 @@
                       # A dict for the test module:
                       #test.baz: {spam: sausage, cheese: bread}
                       #
                      +smtp.fields: id,fun
                      +smtp.from: Kali Salt <admins+salt@kali.org>
                       smtp.to: Kali Admins <admins+salt@kali.org>
                      -smtp.fields: id,fun
                       smtp.host: localhost
                      -smtp.from: Kali Salt <admins+salt@kali.org>
                       smtp.subject: Results of salt actions on

With the change here, this bad behaviour is gone...

Resolves issues introduced in 24ebbb4e0c.

Fix #495

Make the upstream salt package repository selectable, thus allowing the
use of archived salt versions (hosted in
https://archive.repo.saltproject.io), as well as custom salt versions
hosted in alternate repositories.

* CVE-2021-25283 enables Jinja2 safe mode, which breaks use of
  `'dict' in x.__class__.__name__` workaround
* Workaround no longer needed as CentOS 6 is EOL

Use ugly `zypper lr --uri` hack to get around failure if the `base_url`
already exists under a different name:

```
      ID: salt-pkgrepo-install-saltstack-suse
Function: pkgrepo.managed
    Name: systemsmanagement_saltstack_products
  Result: False
 Comment: Failed to configure repo 'systemsmanagement_saltstack_products':
          Repository 'systemsmanagement_saltstack_products' already exists as 'systemsmanagement_saltstack'.
 Started: 09:28:39.154054
Duration: 2760.727 ms
```

Upstream code:

* 45cc49daed/salt/modules/zypperpkg.py (L1262-L1265)

* Semi-automated using https://github.com/myii/ssf-formula/pull/285

When running a high-state on the salt-master to deploy itself, the run fails
with an Authentication error occurred because the master restarts half way though.

* Automated using https://github.com/myii/ssf-formula/pull/237

* add `-` if someone supplies `py3` in pillar, like other platforms

X

Available only on Debian family OS-es

Instead of the default service.running + enabled, you can control
the actual state, via pillar.
And you can even say 'state = ignore' and no state will be generated
to control the service