Resolves ansible 2.9+, Mitogen, and Python 3.5 setup module issue

[s1113950]

fixes #672

[lunarfs]

Let me know when you think the PR is in a state where i can try it out on our code, the i will give feedback on it. Thanks for spending your time on this!

[s1113950]

Will do! :) I'm currently active in the job market so I haven't had a ton of extra time to spend on this but I hope to finish it in the next few days.

I see 2 options:

1. If python3.5 is ran on the target system, edit the Ansible source code to not relative import in the setup module on the fly + possible try-finally approach in Mitogen's planner, so that after it runs a setup module, if target system was 3.5.1-3.5.3 then change back source to what it was before
   --> not ideal, I don't think Mitogen should be changing source code on a system, even if it is Ansible. The finally part could revert the change, but if it somehow has a bug in it then someone's Ansible could be stuck with the new import change.

2. If python3.5 is ran on the target system, when Mitogen copies over the source for a module if it's the setup module then edit the source in memory and send over a new copy --> preferred approach, issue with this is so far the way I've found to do this is by putting ansible-specific code in the propagate_to() function in mitogen/service.py, which isn't supposed to contain Ansible-specific logic (that goes in ansible_mitogen rather than mitogen).

WDYT @lunarfs ? How would you feel if Mitogen changed Ansible source in the setup module to not do from ...module_utils.basic but instead changed it to absolute import if target was 3.5.1-3.5.3?

The problem is on Mitogen's side because it works with vanilla Ansible, but it only breaks with 3 old versions of Python3.5, and I couldn't figure out the root cause other than the relative import thing :( I'm thinking the most optimal solution time-wise is to change relative to absolute import, either permanently or in-mem.

[s1113950]

Scratch my previous comment, I got it working now on my python3.5.3 setup! 😄 @lunarfs please give my patch a try.

[lunarfs]

Hi, thanks!!
I tested this sucessfully today using

ansible 2.9.2
  config file = None
  configured module search path = ['/home/ansibleme/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /usr/local/lib/python3.8/site-packages/ansible
  executable location = /usr/local/bin/ansible
  python version = 3.8.1 (default, Feb 19 2020, 08:27:01) [GCC 4.8.5 20150623 (Red Hat 4.8.5-39)]

I know that this is a bit different from the test scenario.

[s1113950]

Nice!! I'm gonna merge the patch then; 1 test scenario is failing because of an unrelated issue: #723 .