<!--- Verify first that your issue is not already reported on GitHub -->
<!--- Also test if the latest release and devel branch are affected too -->
<!--- Complete *all* sections as described, this form is processed automatically -->

##### SUMMARY
A task running locally that uses a file-type module can encounter a traceback due to a “invalid cross-device link” when ansible is running inside of a container with mounted volumes. This is due to a common practice where a module writes to `ansible_remote_tmp` as a staging area, and then uses [module_utils](https://github.com/ansible/ansible/blob/42bc03f0f5740f2340fcdbe75557920552622ac3/lib/ansible/module_utils/basic.py#L2328) to copy it over.

The error happens when either `ansible_remote_tmp` is outside the volume and the destination is inside the volume, or vice versa.

This is an example, but it applies to other modules:
```
- name: write something to a file in the volume (this fails)
  copy:
    content: "foo_bar"
    dest: "/elijah/file_for_elijah.txt"
```

Here, `/elijah` is the mounted volume.

What the task wants:
I have a string “foo_bar”
Write this string to a new file
This file is in a mounted volume
I have permission to write to this file and volume
No cross-volume writing necessary from user perspective

What ansible does:
Writes a temporary file to /tmp
This is from their Ansible tmp dir setting, which is configurable
Tries to move this file from the tmp location to the mounted volume
The user never told them to do this
Permission error due to attempted cross-volume move
Moves can be allowed by making “unsafe”

Running inside of a container with mounted volumes is fundamental to the design of execution environments.

##### ISSUE TYPE
- Bug Report

##### COMPONENT NAME
lib/ansible/module_utils/basic.py

##### ANSIBLE VERSION
<!--- Paste verbatim output from "ansible --version" between quotes -->
Tested with ansible 2.9.15 and devel
Reproducer provided requires containers.podman collection

##### CONFIGURATION
<!--- Paste verbatim output from "ansible-config dump --only-changed" between quotes -->
```paste below
<none>
```

##### OS / ENVIRONMENT
Redhat type linux with podman installed


##### STEPS TO REPRODUCE
<!--- Describe exactly how to reproduce the problem, using a minimal test-case -->

<!--- Paste example playbooks or commands between quotes below -->
Playbook requirements:
ansible-galaxy collection install containers.podman 
Have podman installed locally

Run this playbook locally against localhost inventory:

https://github.com/AlanCoding/utility-playbooks/blob/master/issues/elijah.yml

```
ansible-playbook -i localhost, elijah.yml
```

This:
Starts a container, with `/elijah` (in the container) mounted to the `playbook_dir` (on host machine)
Templates a file outside the volume mount (successful)
Templates a file inside the volume mount (not successful)
Stops and removes the container


<!--- HINT: You can paste gist.github.com links for larger files -->

##### EXPECTED RESULTS
<!--- Describe what you expected to happen when running the steps above -->
Able to do basic file operations in execution environments (inside a container), using the host as a staging area

##### ACTUAL RESULTS
<!--- Describe what actually happened. If possible run with extra verbosity (-vvvv) -->

<!--- Paste verbatim command output between quotes -->
``` 
The full traceback is:
Traceback (most recent call last):
  File "/tmp/ansible_ansible.legacy.copy_payload_ntnxbqce/ansible_ansible.legacy.copy_payload.zip/ansible/module_utils/basic.py", line 2367, in atomic_move
    os.rename(b_src, b_dest)
OSError: [Errno 18] Invalid cross-device link: b'/root/.ansible/tmp/ansible-tmp-1611160471.6475317-1020701-11385651364745/source' -> b'/elijah/file_for_elijah.txt'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib64/python3.6/shutil.py", line 550, in move
    os.rename(src, real_dst)
OSError: [Errno 18] Invalid cross-device link: b'/root/.ansible/tmp/ansible-tmp-1611160471.6475317-1020701-11385651364745/source' -> b'/elijah/.ansible_tmp7di06c3ffile_for_elijah.txt'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/tmp/ansible_ansible.legacy.copy_payload_ntnxbqce/ansible_ansible.legacy.copy_payload.zip/ansible/module_utils/basic.py", line 2409, in atomic_move
    shutil.move(b_src, b_tmp_dest_name)
  File "/usr/lib64/python3.6/shutil.py", line 564, in move
    copy_function(src, real_dst)
  File "/usr/lib64/python3.6/shutil.py", line 264, in copy2
    copystat(src, dst, follow_symlinks=follow_symlinks)
  File "/usr/lib64/python3.6/shutil.py", line 229, in copystat
    _copyxattr(src, dst, follow_symlinks=follow)
  File "/usr/lib64/python3.6/shutil.py", line 165, in _copyxattr
    os.setxattr(dst, name, value, follow_symlinks=follow_symlinks)
PermissionError: [Errno 13] Permission denied: b'/elijah/.ansible_tmp7di06c3ffile_for_elijah.txt'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/tmp/ansible_ansible.legacy.copy_payload_ntnxbqce/ansible_ansible.legacy.copy_payload.zip/ansible/module_utils/basic.py", line 2413, in atomic_move
    shutil.copy2(b_src, b_tmp_dest_name)
  File "/usr/lib64/python3.6/shutil.py", line 264, in copy2
    copystat(src, dst, follow_symlinks=follow_symlinks)
  File "/usr/lib64/python3.6/shutil.py", line 229, in copystat
    _copyxattr(src, dst, follow_symlinks=follow)
  File "/usr/lib64/python3.6/shutil.py", line 165, in _copyxattr
    os.setxattr(dst, name, value, follow_symlinks=follow_symlinks)
PermissionError: [Errno 13] Permission denied: b'/elijah/.ansible_tmp7di06c3ffile_for_elijah.txt'
```

#### ADDITIONAL DETAILS

Ansible is creating the cross-volume write problem, and then requiring the user to solve it by setting “unsafe_writes”. A global setting as suggested by  @bcoca in https://github.com/ansible/ansible/pull/73282 allows them to set it just once, which is better than on each task, or perhaps Tower could set it for them in our use case, but it is a broad sweeping selection that also applies to remote hosts, and that may be undesirable.

We would prefer a solution that doesn’t require the user to solve an implementation problem in ansible.

Hypothetically, the module could detect what volume the destination is in, and use a tmp stage file in that volume.

This is a tower_blocker because we need to replace our use of bwrap and execution environments are in the critical path. We also need users to be able to run their content that used to work in the new process isolation method, which uses containers. Tower setting a global variable that would affect both in-container as well as remote tasks is not acceptable because users security preferences may not allow them to set this for remote tasks, and as mentioned, their defined file operations do not explicitly implicate cross volume mounts. This is purely an ansible imposed situation.

Technical details:
This is a problem shared between many modules because the issue lies in Ansible core module utils
Specific problematic method is: https://github.com/ansible/ansible/blob/42bc03f0f5740f2340fcdbe75557920552622ac3/lib/ansible/module_utils/basic.py#L2328
The traceback (using Ansible devel) will be pasted below

@AlanCoding @chrismeyersfsu and @shanemcd are good contacts on the awx/tower team
'''
    **Deprecated** Use :py:func:`platform.system` directly.
    :returns: Name of the platform the module is running on in a native string
    Returns a native string that labels the platform ("Linux", "Solaris", etc). Currently, this is
    the result of calling :py:func:`platform.system`.
    '''
    return platform.system()
#
#
def load_platform_subclass(cls, *args, **kwargs):