[manual] [PR:19258] Fix shebang to /usr/bin/python in ansible modules for compatibility

[cyw233]

Description of PR

We encountered the following issue when trying to upgrade ansible:
/bin/sh: 1: /usr/bin/env python3: not found
This error occurred when attempting to invoke certain Ansible modules.

According to the Module format and documentation,

the recommended shebang is: `#!/usr/bin/python`

From the logs, we can observe the following behavior:

• When the shebang is /usr/bin/env python, Ansible translates it into:

   203 1751357337.89274: _low_level_execute_command(): starting
   203 1751357337.89277: _low_level_execute_command(): executing: /bin/sh -c ''"'"'/usr/bin/env python'"'"' && sleep 0'

• In contrast, when using /usr/bin/python, Ansible attempts a full interpreter discovery:

   171 1751357179.48738: _low_level_execute_command(): starting
   171 1751357179.48741: _low_level_execute_command(): executing: /bin/sh -c 'echo PLATFORM; uname; echo FOUND; command -v '"'"'python3.13'"'"'; command -v '"'"'python3.12'"'"'; command -v '"'"'python3.11'"'"'; command -v '"'"'python3.10'"'"'; command -v '"'"'python3.9'"'"'; command -v '"'"'python3.8'"'"'; command -v '"'"'/usr/bin/python3'"'"'; command -v '"'"'python3'"'"'; echo ENDFOUND && sleep 0'

This indicates that Ansible treats /usr/bin/env python literally and does not invoke its interpreter auto-discovery logic, leading to failures on systems without the python symlink.

To satisfy the requirements of the latest ansible, we update the shebang lines in all affected modules in advance.

Summary:
Fixes # (issue)

Type of change

• Bug fix
• Testbed and Framework(new/improvement)
• New Test case
  • Skipped for non-supported platforms
• Test case improvement

Back port request

• 202205
• 202305
• 202311
• 202405
• 202411
• 202505

Approach

What is the motivation for this PR?

We encountered the following issue when trying to upgrade ansible:
/bin/sh: 1: /usr/bin/env python3: not found
This error occurred when attempting to invoke certain Ansible modules.

According to the Module format and documentation,

the recommended shebang is: `#!/usr/bin/python`

From the logs, we can observe the following behavior:

• When the shebang is /usr/bin/env python, Ansible translates it into:

   203 1751357337.89274: _low_level_execute_command(): starting
   203 1751357337.89277: _low_level_execute_command(): executing: /bin/sh -c ''"'"'/usr/bin/env python'"'"' && sleep 0'

• In contrast, when using /usr/bin/python, Ansible attempts a full interpreter discovery:

   171 1751357179.48738: _low_level_execute_command(): starting
   171 1751357179.48741: _low_level_execute_command(): executing: /bin/sh -c 'echo PLATFORM; uname; echo FOUND; command -v '"'"'python3.13'"'"'; command -v '"'"'python3.12'"'"'; command -v '"'"'python3.11'"'"'; command -v '"'"'python3.10'"'"'; command -v '"'"'python3.9'"'"'; command -v '"'"'python3.8'"'"'; command -v '"'"'/usr/bin/python3'"'"'; command -v '"'"'python3'"'"'; echo ENDFOUND && sleep 0'

This indicates that Ansible treats /usr/bin/env python literally and does not invoke its interpreter auto-discovery logic, leading to failures on systems without the python symlink.

To satisfy the requirements of the latest ansible, we update the shebang lines in all affected modules in advance.

How did you do it?

To satisfy the requirements of the latest ansible, this PR updates the shebang lines in all affected modules to #!/usr/bin/python.

How did you verify/test it?

We need to make sure that this change won't affect current test firstly -- test by pipeline itself. And then, we need to make sure that this change works in the new version -- test locally.

Any platform specific information?

Supported testbed topology if it's a new test case?

Documentation

[cyw233]

Original PR: sonic-net/sonic-mgmt#19258