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

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

* Checked using https://github.com/myii/ssf-formula/pull/131

```bash
Examining salt/syndic.sls of type state
[201] Trailing whitespace
salt/syndic.sls:12
  {%- endif %}
```