FIX remove link to resource_tracker._pid in child processes

[tomMoral]

Fix for joblib/joblib#1708.

[fcharras]

Thanks for investigating that this fast @tomMoral

From what I've read from the code so far, this looks good to me (+ the extra resulting simplification on tracker_args -> tracker_fd).

What I intended to do initially is to try to monkey patch resource_tracker._stop and try to detect when it's called in __delete__ (using traceback inspection) and have it exit early in this case, to ensure only minimal differences between parent and child processes.

This is much simpler and indeed setting ._pid to None prevents the wrong code path, can we safely assume that no user code ever tries to explicitly stop the resource_tracker in loky processes ? (probably safe to assume since _pid and _stop are not public anyway...)

(The ci failing on windows looks like an actual remaining bug.)

[tomMoral]

Yes, it is safe to assume that we can modify private info.
But the issue we still need to investigate is the failure on windows which looks reproducible..

[fcharras]

I have investigated the remaining issue in a windows VM.

The current issue arises when the parent process garbage collects the loky resource tracker.

The __del__ is only called once, but for some reason it fails regardless, the process of this resource tracker must have already been terminated somehow in another way.

There are no issues with the resource tracker from multiprocessing library.

Since this remaining windows issue is about the loky resource tracker, there's an easy fix: a quick workaround to could be to override loky resource tracker del method to just do nothing (or, only do nothing on windows).

So far I don't know why the loky resource tracker process is cleant before the garbage collection of the resource tracker object. If we can find out maybe there would be a cleaner fix.