Update "yaml" code-block references with "jinja" where needed

There are many `.. code-block: yaml` definitions that should really
be `.. code-block: jinja` definitions. This commit cleans up some
of those and removes warnings like these from the doc build:

```
WARNING: Could not lex literal_block as "yaml". Highlighting skipped.
```

doc/faq.rst

@@ -268,7 +268,7 @@ derivatives start the service after the package installation by default.
 To prevent this, we need to create policy layer which will prevent the Minion
 service to restart right after the upgrade:
 
-.. code-block:: yaml
+.. code-block:: jinja
 
     {%- if grains['os_family'] == 'Debian' %}
 
@@ -316,7 +316,7 @@ Restart using states
 Now we can apply the workaround to restart the Minion in reliable way.
 The following example works on both UNIX-like and Windows operating systems:
 
-.. code-block:: yaml
+.. code-block:: jinja
 
     Restart Salt Minion:
       cmd.run:
@@ -333,7 +333,7 @@ However, it requires more advanced tricks to upgrade from legacy version of
 Salt (before ``2016.3.0``), where executing commands in the background is not
 supported:
 
-.. code-block:: yaml
+.. code-block:: jinja
 
     Restart Salt Minion:
       cmd.run:

doc/topics/jinja/index.rst

@@ -18,7 +18,7 @@ are run.
 The most basic usage of Jinja in state files is using control structures to
 wrap conditional or redundant state elements:
 
-.. code-block:: yaml
+.. code-block:: jinja
 
     {% if grains['os'] != 'FreeBSD' %}
     tcsh:
@@ -43,7 +43,7 @@ Writing **if-else** blocks can lead to very redundant state files however. In
 this case, using :ref:`pillars<pillar>`, or using a previously
 defined variable might be easier:
 
-.. code-block:: yaml
+.. code-block:: jinja
 
     {% set motd = ['/etc/motd'] %}
     {% if grains['os'] == 'Debian' %}
@@ -61,7 +61,7 @@ list of MOTD files to update, adding a state block for each file.
 
 The filter_by function can also be used to set variables based on grains:
 
-.. code-block:: yaml
+.. code-block:: jinja
 
    {% set auditd = salt['grains.filter_by']({
    'RedHat': { 'package': 'audit' },
@@ -76,7 +76,7 @@ Include and Import
 Includes and imports_ can be used to share common, reusable state configuration
 between state files and between files.
 
-.. code-block:: yaml
+.. code-block:: jinja
 
     {% from 'lib.sls' import test %}
 
@@ -85,7 +85,7 @@ state element, from the file ``lib.sls``. In the case that the included file
 performs checks again grains, or something else that requires context, passing
 the context into the included file is required:
 
-.. code-block:: yaml
+.. code-block:: jinja
 
     {% from 'lib.sls' import test with context %}
 
@@ -95,7 +95,7 @@ Including Context During Include/Import
 By adding ``with context`` to the include/import directive, the
 current context can be passed to an included/imported template.
 
-.. code-block:: yaml
+.. code-block:: jinja
 
     {% import 'openssl/vars.sls' as ssl with context %}
 
@@ -110,7 +110,7 @@ mini-templates to repeat blocks of strings with a few parameterized variables.
 Be aware that stripping whitespace from the template block, as well as
 contained blocks, may be necessary to emulate a variable return from the macro.
 
-.. code-block:: yaml
+.. code-block:: jinja
 
     # init.sls
     {% from 'lib.sls' import pythonpkg with context %}
@@ -123,7 +123,7 @@ contained blocks, may be necessary to emulate a variable return from the macro.
       pkg.installed:
         - name: {{ pythonpkg('fabric') }}
 
-.. code-block:: yaml
+.. code-block:: jinja
 
     # lib.sls
     {% macro pythonpkg(pkg) -%}
@@ -161,13 +161,13 @@ strftime
   :ref:`exhaustive list <python2:strftime-strptime-behavior>` can be found in
   the official Python documentation.
 
-  .. code-block:: yaml
+  .. code-block:: jinja
 
       {% set curtime = None | strftime() %}
 
   Fuzzy dates require the `timelib`_ Python module is installed.
 
-  .. code-block:: yaml
+  .. code-block:: jinja
 
       {{ "2002/12/25"|strftime("%y") }}
       {{ "1040814000"|strftime("%Y-%m-%d") }}
@@ -184,7 +184,7 @@ yaml_encode
   unicode.  It will *not* work for multi-objects such as sequences or
   maps.
 
-  .. code-block:: yaml
+  .. code-block:: jinja
 
       {%- set bar = 7 %}
       {%- set baz = none %}
@@ -209,7 +209,7 @@ yaml_dquote
   resulting string will be emitted with opening and closing double
   quotes.
 
-  .. code-block:: yaml
+  .. code-block:: jinja
 
       {%- set bar = '"The quick brown fox . . ."' %}
       {%- set baz = 'The word of the day is "salty".' %}
@@ -249,7 +249,7 @@ Jinja_ can be used in the same way in managed files:
             - context:
                 bind: 127.0.0.1
 
-.. code-block:: yaml
+.. code-block:: jinja
 
     # lib.sls
     {% set port = 6379 %}
@@ -327,7 +327,7 @@ dictionary of :term:`execution function <Execution Function>`.
 
 .. versionadded:: 2014.7.0
 
-.. code-block:: yaml
+.. code-block:: jinja
 
     # The following two function calls are equivalent.
     {{ salt['cmd.run']('whoami') }}
@@ -341,7 +341,7 @@ in the current Jinja context.
 
 .. versionadded:: 2014.7.0
 
-.. code-block:: yaml
+.. code-block:: jinja
 
     Context is: {{ show_full_context() }}
 
@@ -356,7 +356,7 @@ distribute to Salt minions.
 Functions in custom execution modules are available in the Salt execution
 module dictionary just like the built-in execution modules:
 
-.. code-block:: yaml
+.. code-block:: jinja
 
     {{ salt['my_custom_module.my_custom_function']() }}
 

doc/topics/pillar/index.rst

@@ -90,7 +90,7 @@ by their ``os`` grain:
 
 ``/srv/pillar/packages.sls``
 
-.. code-block:: yaml
+.. code-block:: jinja
 
     {% if grains['os'] == 'RedHat' %}
     apache: httpd
@@ -116,13 +116,13 @@ of ``Foo Industries``.
 Consequently this data can be used from within modules, renderers, State SLS
 files, and more via the shared pillar :ref:`dict <python2:typesmapping>`:
 
-.. code-block:: yaml
+.. code-block:: jinja
 
     apache:
       pkg.installed:
         - name: {{ pillar['apache'] }}
 
-.. code-block:: yaml
+.. code-block:: jinja
 
     git:
       pkg.installed:
@@ -155,7 +155,7 @@ And the actual pillar file at '/srv/pillar/common_pillar.sls':
     environment has its own top file, the jinja placeholder ``{{ saltenv }}``
     can be used in place of the environment name:
 
-    .. code-block:: yaml
+    .. code-block:: jinja
 
         {{ saltenv }}:
           '*':

doc/topics/reactor/index.rst

@@ -75,7 +75,7 @@ They differ because of the addition of the ``tag`` and ``data`` variables.
 
 Here is a simple reactor sls:
 
-.. code-block:: yaml
+.. code-block:: jinja
 
     {% if data['id'] == 'mysql1' %}
     highstate_run:
@@ -92,7 +92,7 @@ API and the runner system.  In this example, a command is published to the
 ``mysql1`` minion with a function of :py:func:`state.apply
 <salt.modules.state.apply_>`. Similarly, a runner can be called:
 
-.. code-block:: yaml
+.. code-block:: jinja
 
     {% if data['data']['orchestrate'] == 'refresh' %}
     orchestrate_run:
@@ -145,15 +145,15 @@ so using the Reactor to kick off an Orchestrate run is a very common pairing.
 
 For example:
 
-.. code-block:: yaml
+.. code-block:: jinja
 
     # /etc/salt/master.d/reactor.conf
     # A custom event containing: {"foo": "Foo!", "bar: "bar*", "baz": "Baz!"}
     reactor:
       - myco/custom/event:
         - /srv/reactor/some_event.sls
 
-.. code-block:: yaml
+.. code-block:: jinja
 
     # /srv/reactor/some_event.sls
     invoke_orchestrate_file:
@@ -163,7 +163,7 @@ For example:
             event_tag: {{ tag }}
             event_data: {{ data | json() }}
 
-.. code-block:: yaml
+.. code-block:: jinja
 
     # /srv/salt/orch/do_complex_thing.sls
     {% set tag = salt.pillar.get('event_tag') %}
@@ -463,7 +463,7 @@ from the event to the state file via inline Pillar.
 
 :file:`/srv/salt/haproxy/react_new_minion.sls`:
 
-.. code-block:: yaml
+.. code-block:: jinja
 
     {% if data['act'] == 'accept' and data['id'].startswith('web') %}
     add_new_minion_to_pool:
@@ -507,7 +507,7 @@ won't yet direct traffic to it.
 
 :file:`/srv/salt/haproxy/refresh_pool.sls`:
 
-.. code-block:: yaml
+.. code-block:: jinja
 
     {% set new_minion = salt['pillar.get']('new_minion') %}
 
@@ -557,7 +557,7 @@ authentication every ten seconds by default.
 
 :file:`/srv/reactor/auth-pending.sls`:
 
-.. code-block:: yaml
+.. code-block:: jinja
 
     {# Ink server failed to authenticate -- remove accepted key #}
     {% if not data['result'] and data['id'].startswith('ink') %}
@@ -583,7 +583,7 @@ Ink servers in the master configuration.
 
 :file:`/srv/reactor/auth-complete.sls`:
 
-.. code-block:: yaml
+.. code-block:: jinja
 
     {# When an Ink server connects, run state.apply. #}
     highstate_run:
@@ -613,7 +613,7 @@ each minion fires when it first starts up and connects to the master.
 On the master, create **/srv/reactor/sync_grains.sls** with the following
 contents:
 
-.. code-block:: yaml
+.. code-block:: jinja
 
     sync_grains:
       local.saltutil.sync_grains:

doc/topics/targeting/nodegroups.rst

@@ -122,7 +122,7 @@ example, to check if a minion is in the 'webserver' nodegroup:
     nodegroups:
       webserver: 'G@os:Debian and L@minion1,minion2'
 
-.. code-block:: yaml
+.. code-block:: jinja
 
     {% if grains.id in salt['pillar.get']('master:nodegroups:webserver', [])
     and grains.os in salt['pillar.get']('master:nodegroups:webserver', []) %}

doc/topics/tutorials/starting_states.rst

@@ -367,7 +367,7 @@ for the Grains to be accessed from within the template. A few examples:
 
 ``apache/init.sls:``
 
-.. code-block:: yaml
+.. code-block:: jinja
 
     apache:
       pkg.installed:
@@ -411,7 +411,7 @@ a MooseFS distributed filesystem chunkserver:
 
 ``moosefs/chunk.sls:``
 
-.. code-block:: yaml
+.. code-block:: jinja
 
     include:
       - moosefs

doc/topics/tutorials/states_pt3.rst

@@ -93,7 +93,7 @@ variable in a Salt state.
 
    MYENVVAR="world" salt-call state.template test.sls
 
-.. code-block:: yaml
+.. code-block:: jinja
 
    Create a file with contents from an environment variable:
      file.managed:
@@ -102,7 +102,7 @@ variable in a Salt state.
 
 Error checking:
 
-.. code-block:: yaml
+.. code-block:: jinja
 
    {% set myenvvar = salt['environ.get']('MYENVVAR') %}
    {% if myenvvar %}

doc/topics/tutorials/states_pt4.rst

@@ -144,7 +144,7 @@ And finally, the SLS to deploy the website:
 
 ``/srv/salt/prod/webserver/foobarcom.sls:``
 
-.. code-block:: yaml
+.. code-block:: jinja
 
     {% if pillar.get('webserver_role', '') %}
     /var/www/foobarcom: