Fix trailing space in ec2_vol example, fix 'the the' typos (#28440)

* Fix 'the the' typos, fix 'pahting' filename typo

* Change 'the the' typos to a single 'the'.
* Change `playbook_pahting.rst` to `playbook_pathing.rst`.

* Delete trailing space in ec2_vol example

Delete the trailing space in `instance: "{{ item.id }} "`, which makes the
example fail when run because it looks for instance "i-xxxx ".

docs/docsite/rst/guide_aws.rst

@@ -117,7 +117,7 @@ From this, we'll use the add_host module to dynamically create a host group cons
          add_host: hostname={{ item.public_ip }} groups=ec2hosts
          with_items: "{{ ec2.instances }}"
 
-With the host group now created, a second play at the bottom of the the same provisioning playbook file might now have some configuration steps::
+With the host group now created, a second play at the bottom of the same provisioning playbook file might now have some configuration steps::
 
     # demo_setup.yml
 

docs/docsite/rst/playbook_pathing.rst

@@ -20,7 +20,7 @@ Some tasks that require 'local' resources use action plugins (template and copy
 The magic of 'local' paths
 --------------------------
 
-Lookups and action plugins both use a special 'search magic' to find things, taking the current play into account, it uses from most specific to most general the the playbook dir in which a task is contained (this includes roles and includes).
+Lookups and action plugins both use a special 'search magic' to find things, taking the current play into account, it uses from most specific to most general playbook dir in which a task is contained (this includes roles and includes).
 
 Using this magic, relative paths get attempted first with a 'files|templates|vars' appended (if not already present), depending on action being taken, 'files' is the default. (i.e include_vars will use vars/).  The paths will be searched from most specific to most general (i.e role before play).
 dependent roles WILL be traversed (i.e task is in role2, role2 is a dependency of role1, role2 will be looked at first, then role1, then play).

docs/docsite/rst/playbooks_checkmode.rst

@@ -33,7 +33,7 @@ There are two options:
 1. Force a task to **run in check mode**, even when the playbook is called **without** ``--check``. This is called ``check_mode: yes``.
 2. Force a task to **run in normal mode** and make changes to the system, even when the playbook is called **with** ``--check``. This is called ``check_mode: no``.
 
-.. note:: Prior to version 2.2 only the the equivalent of ``check_mode: no`` existed. The notation for that was ``always_run: yes``.
+.. note:: Prior to version 2.2 only the equivalent of ``check_mode: no`` existed. The notation for that was ``always_run: yes``.
 
 Instead of ``yes``/``no`` you can use a Jinja2 expression, just like the ``when`` clause.
 
@@ -51,7 +51,7 @@ Example::
 
 
 Running single tasks with ``check_mode: yes`` can be useful to write tests for
-ansible modules, either to test the module itself or to the the conditions under
+ansible modules, either to test the module itself or to the conditions under
 which a module would make changes. 
 With ``register`` (see :doc:`playbooks_conditionals`) you can check the
 potential changes.

docs/docsite/rst/playbooks_filters.rst

@@ -6,7 +6,7 @@ Filters
 
 Filters in Ansible are from Jinja2, and are used for transforming data inside a template expression.  Jinja2 ships with many filters. See `builtin filters`_ in the official Jinja2 template documentation.
 
-Take into account that templating happens on the the Ansible controller, **not** on the task's target host, so filters also execute on the controller as they manipulate local data.
+Take into account that templating happens on the Ansible controller, **not** on the task's target host, so filters also execute on the controller as they manipulate local data.
 
 In addition the ones provided by Jinja2, Ansible ships with it's own and allows users to add their own custom filters.