Salt writes it's schedule file to /etc/salt/{minion,master}.d/_schedule.conf

We don't want to stomp all over Salt's files, but we do want a pristine
starting point to lay down our managed config. So we use clean: True on the
file.recurse call, but we tell it to ignore files that start with an _

We have to rename the current config file (_defaults.conf) because it will be
ignored by the rule that ignores Salt's _* config files.

This also means we need to clean up old config files (_defaults.conf) and
restart the service if we cleaned it up.

see pillar.example for configuration

If those options are set in pillar data, the jinja template
salt/files/master.d/_defaults.conf would fail to compile trying to
evaluate non-existing variables.

Replace those variables with the corresponding dictionnary entries.

This is only needed for salt versions older than 2014.7 that do not
define the global "salt" variable in such context.

Most include do not expect salt to be something else than the usual salt
variable giving access to all the salt modules. Instead we use cfg_salt.
And for consistency we rename the master/minion variables to
cfg_master/cfg_minion too.

In Python 3, dict.items() is already an iterator while dict.iteritems() no
longer exits. In Python 2, dict.items() is not an iterator but it works
and the small performance hit doesn't really matter for the salt config
pillar data which is really small.

Otherwise you get an “ValueError: too many values to unpack” exception
when you make use of those entries in your pillar data.

This state downloads formulas from git repositories and ensures
that they are recorded in the file_roots setting.

Fixed explanations, and improved logic code to client_acl

better newlines with iterations.

I don't understand why unnecessary ``-`` were added after and before ``{%-`` and ``-%}``

https://github.com/saltstack-formulas/salt-formula/issues/64

Fixes issue where a gitfs remote that has no child options would cause an
error. Also fix up bad yaml in pillar example.

Commit 2b51a6f0c3 introduced options for gitfs_remotes in a pillar by using a jinja test to see if a parameter is a mapping (dict etc.). This feature however is only available in jinja 2.6 or newer (see http://jinja.pocoo.org/docs/dev/templates/#mapping).
Although this version of Jinja is available on Ubuntu, other OS / package managers do provide older versions (2.2.1 in RedHat 6).

This change makes use of the "iterable" test which should do the exact same thing.

Reference about this config value: http://docs.saltstack.com/en/latest/ref/configuration/master.html#yaml-utf8
Reference why this might be useful: https://github.com/saltstack/salt/issues/3436#issuecomment-61225863

This allows users to easily add configuration settings that the formula
doesn't yet provide, without having to modify the existing templates.

Fixes #48

See #37 "Fixed file_roots config generation with several environment"

Fixed an apparent typo in the autoreject_file setting (which was listed as autorejecte_file)

made fileserver_backend and gitfs_remotes look more like expected