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

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...

* 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

This prevents the `return` key being duplicated in the minion config by L1205

Signed-off-by: Johannes Löthberg <johannes@kyriasis.com>

Remove commented version and associated comment, as we still have the same
option earlier in config with an other valid comment.

closes #367

* Minion/returner/elasticsearch yaml read fix.

* Improved the documentation for the elasticsearch returner

* Added quotration around globing rules

Proposed pull request for elasticsearch returner in the minion.d/f_defaults.conf file

I use Salt environments to provide each of my team mates the ability to develop
and test their Salt changes. And I've found that when we run this formula from
our environments against our salt-master, comments in some files change. For us
this represents an unwanted and unplanned change. I understand the intention -
to identify how or why the file changed, but I firmly believe that we should
be able to run highstsate with test=True and only see intended changes. Here's
an example:

            ID: salt-cloud-providers
      Function: file.recurse
          Name: /etc/salt/cloud.providers.d
        Result: None
       Comment: #### /etc/salt/cloud.providers.d/saltify.conf ####
                The file /etc/salt/cloud.providers.d/saltify.conf is set to be changed
       Started: 20:01:28.586441
      Duration: 75.185 ms
       Changes:
                ----------
                /etc/salt/cloud.providers.d/saltify.conf:
                    ----------
                    diff:
                        ---
                        +++
                        @@ -1,4 +1,4 @@
                        -# This file is managed by Salt via salt://salt/files/cloud.providers.d/saltify.conf?saltenv=myenv
                        +# This file is managed by Salt via salt://salt/files/cloud.providers.d/saltify.conf?saltenv=dev

                         saltify:
                           provider: saltify

This now properly also supports per user, per minion as well as
function argument limiting.

As discussed in PR#305, these are defaults that even if they are
configurable as probably not suited to a majority of users and causes
delete/add output on highstate of user of the formula choses to use
the same file name.

Added parameters new to 2016.03 (or simply missing in the existing config).

pillar (backwards compatibility)

Checks for 'dict' in `x.__class__.__name__` b/c
neither `type()` nor `isinstance()` is available.

!!   Not tested with an actual   !!
 !!  configured `ext_pillar` yet  !!

- jinja on RHEL/CentOS 6 has no 'mapping'
  test (see salt-formula issue #193)
- {% do ... %} allows no assignment, only
  function calls
- of course, `type(foo) is dict` doesn't
  work because it's no jinja test
- maybe `.isinstance()` would be nicer/more
  reliable

Some vars were missing {{ }}
Indentation was broken
isinstance is not available in Salt