Accept multi-token interchange launch commands

[rjmello]

Description

We now accept a string or a list of strings for interchange_launch_cmd to support multi-token commands.

We also no longer encode the interchange launch command before passing it to subprocess.Popen() because strings are sufficient.

Type of change

• Bug fix

[benclifford]

this is repeatedly failing in CI with failures that look race-condition like to me - for example, like #3540

Maybe it's bad luck, maybe this change happens to stir up those race conditions a bit more.

[rjmello]

Maybe it's bad luck, maybe this change happens to stir up those race conditions a bit more.

Yeah, I think you're right; the additional shell process could be the culprit. I went this route to match how the LocalChannel launches the worker pool, but I think the simpler, more secure approach is to accept a list of command tokens rather than rely on an additional shell process to interpret the command. We may want to consider doing the same for the worker pool launch command.

[benclifford]

I don't have any strong opinions either way - security wise from a pure Parsl perspective the config is trusted, although I appreciate that in Globus Compute multi-user land that might not be so (and there you have to make your own arguments).

I do feel that the Parsl test suite should be resilient to this kind of change though - it's shouldn't be breaking just because of some irrelevant process related administrivia like this.

[rjmello]

I agree, but I think we should address that longstanding issue in a subsequent PR.

[benclifford]

could make this only take a sequence of strings, and remove the before-this-PR accept-one-string behaviour? I don't think backwards compatibility matters too much here and it would remove the complexity of having two options - one option that isn't very interesting and is probably confusing for a user trying to specify "my-interchange --myopt" as a string, which doesn't work but does typecheck.

[rjmello]

If we aren't worried about backwards compatibility, then I definitely agree. Just pushed an update.

[benclifford]

i don't think it's a concern -- this only appears in #3514 released earlier this month and I haven't heard of or imagined anyone wanting to use it apart from the specific use case you are trying to address with Globus Compute.