Last docs link fixes (#39391) (#39445)

* should not need <>, but fails without

* adds anchor to keywords page, uses it on plugins pages

* fixes envvar link errors

* harmonize file name and ref name as python_3

(cherry picked from commit c8a9b411bc)

docs/docsite/rst/dev_guide/developing_modules.rst

@@ -87,7 +87,7 @@ The following topics will discuss how to develop and work with modules:
      Checklist for contributing your module to Ansible.
 :doc:`testing`
     Developing unit and integration tests.
-:doc:`developing_python3`
+:ref:`developing_python_3`
     Adding Python 3 support to modules (all new modules must be Python-2.6 and Python-3.5 compatible).
 :doc:`developing_modules_in_groups`
     A guide for partners wanting to submit multiple modules.

docs/docsite/rst/dev_guide/developing_modules_checklist.rst

@@ -23,7 +23,7 @@ The following  checklist items are important guidelines for people who want to c
 
 * The shebang must always be ``#!/usr/bin/python``.  This allows ``ansible_python_interpreter`` to work
 * Modules must be written to support Python 2.6. If this is not possible, required minimum Python version and rationale should be explained in the requirements section in ``DOCUMENTATION``.  In Ansible-2.3 the minimum requirement for modules was Python-2.4.
-* Modules must be written to use proper Python-3 syntax.  At some point in the future we'll come up with rules for running on Python-3 but we're not there yet.  See :doc:`developing_python3` for help on how to do this.
+* Modules must be written to use proper Python-3 syntax.  At some point in the future we'll come up with rules for running on Python-3 but we're not there yet.  See :doc:`developing_python_3` for help on how to do this.
 * Modules must have a metadata section.  For the vast majority of new modules,
   the metadata should look exactly like this:
 
@@ -131,8 +131,8 @@ Read the complete :ref:`module metadata specification <ansible_metadata_block>`
   module_utils.urls.fetch_url().  If you use those you may find you also want
   to fallback on environment variables for default values.  If you do that,
   be sure to use non-generic environment variables (like
-  :envvar:`API_<MODULENAME>_USERNAME`).  Using generic environment variables
-  like :envvar:`API_USERNAME` would conflict between modules.
+  :code:`API_<MODULENAME>_USERNAME`).  Using generic environment variables
+  like :code:`API_USERNAME` would conflict between modules.
 
 Windows modules checklist
 =========================

docs/docsite/rst/dev_guide/developing_modules_general_windows.rst

@@ -342,7 +342,7 @@ the most popular are
 To be able to view the arguments as passed by Ansible to the module follow
 these steps.
 
-- Prefix the Ansible command with :envvar:`ANSIBLE_KEEP_REMOTE_FILES=1` to specify that Ansible should keep the exec files on the server.
+- Prefix the Ansible command with :envvar:`ANSIBLE_KEEP_REMOTE_FILES=1<ANSIBLE_KEEP_REMOTE_FILES>` to specify that Ansible should keep the exec files on the server.
 - Log onto the Windows server using the same user account that Ansible used to execute the module.
 - Navigate to ``%TEMP%\..``. It should contain a folder starting with ``ansible-tmp-``.
 - Inside this folder, open the PowerShell script for the module.

docs/docsite/rst/dev_guide/index.rst

@@ -19,7 +19,7 @@ To get started, select one of the following topics.
    developing_plugins
    developing_inventory
    developing_core
-   developing_python3
+   developing_python_3
    developing_api
    developing_rebasing
    testing

docs/docsite/rst/plugins/connection.rst

@@ -29,7 +29,7 @@ into the ``connection_plugins`` directory.
 Using Connection Plugins
 ++++++++++++++++++++++++
 
-The transport can be changed via :ref:`configuration<ansible_configuration_settings>`, at the command line (``-c``, ``--connection``), as a :ref:`keyword <playbooks_keywords>` in your play, or by setting a :ref:`variable<behavioral_parameters>`, most often in your inventory.
+The transport can be changed via :ref:`configuration<ansible_configuration_settings>`, at the command line (``-c``, ``--connection``), as a :ref:`keyword <playbook_keywords>` in your play, or by setting a :ref:`variable<behavioral_parameters>`, most often in your inventory.
 For example, for Windows machines you might want to use the :doc:`winrm<connection/winrm>` plugin.
 
 Most connection plugins can operate with a minimum configuration. By default they use the :ref:`inventory hostname<inventory_hostnames_lookup>` and defaults to find the target host.

docs/docsite/rst/plugins/strategy.rst

@@ -34,7 +34,7 @@ or in the `ansible.cfg` file:
     [defaults]
     strategy=linear
 
-You can also specify the strategy plugin in the play via the :ref:`strategy keyword <playbooks_keywords>` in a play::
+You can also specify the strategy plugin in the play via the :ref:`strategy keyword <playbook_keywords>` in a play::
 
   - hosts: all
     strategy: debug

docs/docsite/rst/reference_appendices/faq.rst

@@ -195,7 +195,7 @@ is likely the problem. There are several workarounds:
 
     solaris1 ansible_remote_tmp=$HOME/.ansible/tmp
 
-* You can set :ref:`ansible_shell_executable` to the path to a POSIX compatible shell.  For
+* You can set :ref:`ansible_shell_executable<ansible_shell_executable>` to the path to a POSIX compatible shell.  For
   instance, many Solaris hosts have a POSIX shell located at :file:`/usr/xpg4/bin/sh` so you can set
   this in inventory like so::
 

docs/templates/playbooks_keywords.rst.j2

@@ -1,3 +1,5 @@
+.. _playbook_keywords:
+
 Playbook Keywords
 =================