docs: Document the PROXY setting and why you would want to use it

[timmc-edx]

I just grabbed the commit message for f4cb95b/PR #36. I haven't actually verified whether this is still accurate -- note that this is from 2015, written for Python 2. For all I know this performance concern is no longer relevant. It also may not be relevant for codejail-service, which is a much smaller process than edxapp.

[MoisesGSalas]

Thanks, even if it no longer applies, having the rationale at hand is much better than doing archeology.

[timmc-edx]

I ended up doing some more research -- and yeah, I suspect this is no longer needed.

Ned confirmed that this was put in place because long-lived edxapp processes would eventually consume more than 50% of RAM and would then be unable to fork. Apparently subprocess execution involves first forking the parent, then having the child run exec to become another process. (I had no idea until today. Seems a bit Rube Goldberg!) Forking causes a copy of the process page tables, and while it's nominally a copy-on-write system, that doesn't help much if the parent is highly active. Ned also noted that Python does a lot of memory writes to update refcounts.

However, I looked into the implementation of subprocess, and it has changed considerably since then! In Python 2.7, it explicitly called os.fork() and then os.execvpe(), as described above. But in 3.11, it tries to call vfork if possible. vfork does not copy the page tables, and instead temporarily blocks the parent and is intended to be used when the fork will then immediately call execve.

So yeah, this looks like an optimization that should now be unnecessary.