### Summary

We have been evaluating an issue that appeared in our collection[ ibm_zos_core version 1.4.0](https://github.com/ansible-collections/ibm_zos_core/tree/v1.4.0) . We import `from ansible.module_utils.basic import AnsibleModule` and use the method [run_command](https://github.com/ansible/ansible/blob/d637e87a9e462b513c5732bd85ba137d03616b36/lib/ansible/module_utils/basic.py#L1841). What we noticed in the users log is that we would occasionally see partial responses to commands our module would execute to determine how our code should react to states on the managed node.

The partial results resulting from [run_command](https://github.com/ansible/ansible/blob/d637e87a9e462b513c5732bd85ba137d03616b36/lib/ansible/module_utils/basic.py#L1841) would either cause our module to fail or an incorrect assumption was made. 

To ensure this was the issue, we took the communities [AnsibleModule](https://github.com/ansible/ansible/blob/0cf9db6fc22bb3b8393506a6577b8ef379148b34/lib/ansible/module_utils/basic.py#L435) source and integrated into our collection temporarily so we could add additional logging and analysis. This code integration allowed us to capture this error "[cmd.stdin.close()",](https://github.com/ansible/ansible/blob/0cf9db6fc22bb3b8393506a6577b8ef379148b34/lib/ansible/module_utils/basic.py#L2050) "BrokenPipeError: [Errno 140] EDC5140I Broken pipe."

Where the full traceback is:
```
"Command run: mvscmdauth --pgm=idcams --sysprint=* --sysin=stdin, with data  LISTCAT ENTRIES('SOME.DATASET.CONTENT')","Command error: [Errno 140] EDC5140I Broken pipe., traceback: Traceback (most recent call last):", "  File \"/tmp/ansible_ibm.ibm_zos_core.zos_copy_payload_yin16b57/ansible_ibm.ibm_zos_core.zos_copy_payload.zip/ansible_collections/ibm/ibm_zos_core/plugins/module_utils/data_set.py\", line 379, in data_set_cataloged", "    rc, stdout, stderr = module.run_command(","  File \"/tmp/ansible_ibm.ibm_zos_core.zos_copy_payload_yin16b57/ansible_ibm.ibm_zos_core.zos_copy_payload.zip/ansible_collections/ibm/ibm_zos_core/plugins/module_utils/ansible_module.py\", line 309, in run_command", "    raise e","  File \"/tmp/ansible_ibm.ibm_zos_core.zos_copy_payload_yin16b57/ansible_ibm.ibm_zos_core.zos_copy_payload.zip/ansible_collections/ibm/ibm_zos_core/plugins/module_utils/ansible_module.py\", line 269, in run_command", "    cmd.stdin.close()",
 "BrokenPipeError: [Errno 140] EDC5140I Broken pipe."
```

This led us to review the communities code and began to strengthen our belief this might be BUFFER related when we saw where the error “cmd.stdin.close()” was thrown here:

```
# No pipes are left to read but process is not yet terminated
# Only then it is safe to wait for the process to be finished
# NOTE: Actually cmd.poll() is always None here if no selectors are left
elif not selector.get_map() and cmd.poll() is None:
     cmd.wait()
     # The process is terminated. Since no pipes to read from are
     # left, there is no need to call select() again.
     break

cmd.stdout.close()
cmd.stderr.close()
selector.close()
```

In [our working branch ](https://github.com/ansible-collections/ibm_zos_core/tree/technical_support/case_728)where we pulled in the community code  for [run_command](https://github.com/ansible-collections/ibm_zos_core/blob/ad981c0f7627578119f3b8860a3f876a97a70cfb/plugins/module_utils/ansible_module.py#L49) we increased the [buffsize](https://docs.python.org/3/library/subprocess.html#popen-constructor) to approximately [16 MB](https://github.com/ansible-collections/ibm_zos_core/blob/a859c9360005f45e7044e08bdfac8567de44a154/plugins/module_utils/ansible_module.py#L221)  and passed that through [kwargs](https://github.com/ansible-collections/ibm_zos_core/blob/a859c9360005f45e7044e08bdfac8567de44a154/plugins/module_utils/ansible_module.py#L221) which allowed the communities code to operate with a larger buffer that resulted in commands results returning correctly.

According to documentation, [subprocess buffsize defaults to -1](https://docs.python.org/3/library/subprocess.html#popen-constructor) which results in **negative bufsize (the default) means the system default of io.DEFAULT_BUFFER_SIZE will be used** where then the devices block size (should be 1024 bytes for z/OS (mainframe Unix)) or the [default value of 1024](https://github.com/python/cpython/blob/f4c03484da59049eb62a9bf7777b963e2267d187/Modules/grpmodule.c#L51) (both resulting in the same value) will be used (which Is much smaller than our 16MB). There was no particular reason we chose 16MB, I think we continued to increase in in each iteration. 

Unfortunately there are no mechanics that we can leverage to allow for a user to change the buffer size, we did consider python environment variable [PYTHONUNBUFFERED](https://github.com/python/cpython/blob/46521826cb1883e29e4640f94089dd92c57efc5b/Python/initconfig.c#L187) but [after reviewing python subprocess](https://github.com/python/cpython/blob/618b7a8260bb40290d6551f24885931077309590/Lib/subprocess.py#L832) we determined it would not help. 

Up to this point, only increased heap would work; after engaging partner engineering they suggested we also pull in pull request [79931](https://github.com/ansible/ansible/pull/79931). In doing so, we had a much better success rate, if i recall out of 150 file copies only 2 failed. We then undid  [79931](https://github.com/ansible/ansible/pull/79931) and returned back to near complete failure so  [79931](https://github.com/ansible/ansible/pull/79931) does seem to help.

### Issue Type

Bug Report

### Component Name

ansible-core , AnsibleModule.run_command()

### Ansible Version

```console
ansible-4.10.0 
ansible-core-2.11.12
```


### Configuration

```console
I am not able to obtain currently, I will need to access the user system: `ansible-config dump --only-changed`
```


### OS / Environment

RHEL8

### Steps to Reproduce

<!--- Paste example playbooks or commands between quotes below -->

I realize that the task I am sharing will not provided you the ability to reproduce, this happens when performing a copy using the IBM zos_copy module thus you will not be able to reproduce it on x86 and will likely need our assistance. 
```
    - name: "Copy a USS directory to another PDS module directory"
      zos_copy:
        src: '{{ item.split(" ")[1] }}'
        dest: '{{ item.split(" ")[4] }}'
        remote_src: true
      loop: "{{ lookup('file', 'deployCopy.txt').split('\n') }}"
      register: copy_result
      ignore_errors: true

```


### Expected Results

I expected the run_command not to fail with and/or return partial responses. 

### Actual Results

```console
Will update.
```


### Code of Conduct

- [X] I agree to follow the Ansible Code of Conduct
:kw cwd: If given, working directory to run the command inside
        :kw use_unsafe_shell: See `args` parameter.  Default False
        :kw prompt_regex: Regex string (not a compiled regex) which can be
            used to detect prompts in the stdout which would otherwise cause
            the execution to hang (especially if no input data is specified)
        :kw environ_update: dictionary to *update* environ variables with
        :kw umask: Umask to be used when running the command. Default None
        :kw encoding: Since we return native strings, on python3 we need to
            know the encoding to use to transform from bytes to text.  If you
            want to always get bytes back, use encoding=None.  The default is
            "utf-8".  This does not affect transformation of strings given as
            args.
        :kw errors: Since we return native strings, on python3 we need to
            transform stdout and stderr from bytes to text.  If the bytes are
            undecodable in the ``encoding`` specified, then use this error
            handler to deal with them.  The default is ``surrogate_or_strict``
            which means that the bytes will be decoded using the
            surrogateescape error handler if available (available on all
            python3 versions we support) otherwise a UnicodeError traceback
            will be raised.  This does not affect transformations of strings
            given as args.
        :kw expand_user_and_vars: When ``use_unsafe_shell=False`` this argument
            dictates whether ``~`` is expanded in paths and environment variables
            are expanded before running the command. When ``True`` a string such as
            ``$SHELL`` will be expanded regardless of escaping. When ``False`` and
            ``use_unsafe_shell=False`` no path or variable expansion will be done.
        :kw pass_fds: When running on Python 3 this argument
            dictates which file descriptors should be passed
            to an underlying ``Popen`` constructor. On Python 2, this will
            set ``close_fds`` to False.