Unfortunately this is not idempotent, however we surely want to sync
everything when salt.minion state is executed.

Change-Id: I0faaf606b57dbd7d009156abfe50d2e5f350190e

This policy will be used for certificate with various keyUsage
parameters. Etcd for example.

Change-Id: I2a6387f8b7ee58fb6f256881e3e09142f13119a9

Change-Id: I1eaa9cf7a7f861cc5de604e03fba8a74436d99ad

By default the check is OK for a number of processes between 1 and 15
but on our machine the number is up to 48. So we set the limit
accordingly.

Change-Id: Iac3d2b91312dfe778ebcd39b5eb985348c7aee5a

Previous approach fails when all of formulas are installed from git.

Change-Id: I0622461ee6469c59c1fd3ad4a23cdaeaeee1b444

Install all pkgs for formulas together.

This error occures when multiple certs signed by same CA are requested
on minion.

Change-Id: I6b20ab4e1795298c94f55fdc61af99f933d8491c

First run is made during salt-master cloud-init and thus it is onchanges
is not suitable here because ca.crt file is already generated.

Letsencrypt could makes symlinks to standard locations in the future.

It was responsible for

    [CRITICAL] Rendering SLS 'base:salt.minion.cert' failed: Jinja variable 'dict object' has no attribute 'cfg01.mk20-lab-advanced.local'
    [ERROR   ] Data passed to highstate outputter is not a valid highstate return: {'local': ["Rendering SLS 'base:salt.minion.cert' failed: Jinja variable 'dict object' has no attribute 'cfg01.mk20-lab-advanced.local'"]}

- allow defining custom key/cert path
- ensure key/cert directories
- set key/cert permissions by metadata