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

Allow to specify reactors separatedly for master and minions

add a way to set which release of saltstack to use

add missing comas

SaltStack provides "versioned" repositories, this commit add a way
to set which release of salt to use.
It adds a pillar "salt:release" which can be set to a specific release
(ex: 2016.11). This release is then used to configure properly the
repositories URLs for Debian/Ubuntu/RedHat.
The default behavior is to point to 'latest', retaining the previous
behavior if the "salt:release" pillar is not set.

Fix rendering of external_auth config.

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

salt-cloud handling cleanups

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.

Since the set of directories is known, just iterate of its well known
names directly. Make sure files are dumped after `file.recurse` to avoid
deletion/creation cycles when applying highstate.

Also apply permissions on cloud.providers.d after all creations steps
are done.

Wrong list name in config file

Updated minion and master config files to 2016.11

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

Add new publisher_acl to salt master config

add salt master config template external_auth settings

add syndic_user option in the master config

pillar (backwards compatibility)

Hack to make rendering work on CentOS 6

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

fixed key reserved for lxc_profile file

fix beacons on dev

Add http proxy support for minion

Fixes jinja in include block

Use a different group name for GID 0 depending on the minion's O/S

fix default dict warning with saltstack dev version

Arch Linux: install pygit2 or libgit2 via pacman instead of source

Alpine Linux: add basic support

Added beacon configuration support

Some Unix variants name GID 0 "wheel".  Unfortunately, one cannot
specify this group by ID, because Python conflates integer 0 with
boolean False, nor can one specify this group using the string '0',
because of assumptions in the Salt or Python codebases regarding group
names.