Should be able to easily set user to `run()` as to another user

[DavidJFelix]

The Popen function can run as another user and the ability to run as another user is critical to certain tasks. While this could be left to run() to call su or sudo there's an opportunity to pull some of the shell logic out into something more platform agnostic.

[bitprophet]

FWIW, about to merge some code that adds the sudo variant on this (a baseline sudo helper was added previously).

One benefit of that approach is it works regardless of backend/subclass; performing a privilege drop via syscall (this ticket) is fine locally but harder to pull off when running over e.g. SSH or (hypothetically) a task queue or other nonlocal context. (And arguably, even if such constructs were capable of doing a similar privilege drop on their end, having them run as root is bad practice anyways.)

---

That aside, leaving this open because it does represent a potentially useful new feature for the Local runner subclass (especially if, as noted in OP, it can be done in a manner that works on systems without sudo, such as Windows or limited Unix environments.)

Offhand implementation concerns:

• For non-pty use case, OP already noted the use of os.setuid/setgid in a "pre-exec" arg to Popen, seems legit
• PTY use case currently uses os.execve; my lower level practical process management is rusty but I think doing an exec after running setuid and friends would have a similar effect here as well (e.g. IIRC that's how forking worker daemons tend to operate). Would have to double check.