Fix module loading in multi-threading environments

[jeblair]

When ansible loads a module from disk for a plugin, it first checks
to see if the module has already been loaded (i.e., exists in
sys.modules), and if it does, it returns that reference rather than
loading the module again (which, as described in issue #13110, must
not happen because repeating the module load may re-initialize
module global variables).

When a module is loaded, the reference is immediately added to
sys.modules, even before the module initialization is complete.
Therefore, if two threads race the module loading code, the first
will begin loading the module from disk, and the second will see
the module in sys.modules. It might begin using that module before
it is even fully loaded, resulting in AttributeErrors on objects
which should be defined in the module.

This change wraps the method which checks for existence in
sys.modules and loads modules from disk in a global mutex so that
more than one module is never loaded from disk at a time.

Fixes #13822

[jimi-c]

Ansible's API has never been advertised as being thread-safe, as we use the multiprocessing library (which does everything in forks). This patch may fix the module loading issue, however I'm sure there are many other places in the code which may harbor similar race conditions. As such, I'm not particularly opposed to this patch, however I am against trying to make the entire API thread safe.

[bcoca]

-1, adding threading and locking code we do not use adds complexity, performance degradation and possible pitfalls for no gain

[emonty]

@jimi-c @bcoca would you accept a patch to the documentation then that says "the python API is known to not be thread safe?" I think that might have prevented confusion in this case.

[jimi-c]

@emonty absolutely.

[bcoca]

done 2374abb