Agent kill_task.sh script should be customizable not to terminate or kill tasks

Current Situation

• The Agent's script ./var_<port>/tmp/kill_task.sh for Unix environments kills all running tasks in case that an Agent looses the connection to the Master or is instructed by the Master to terminate/kill a running task, see JS-1815 and JS-1820.
• The script ./bin/jobscheduler_agent_kill_task.sh is a copy of the Agent's kill script which can be used as template for modifications of the behavior.
• If a custom kill script is to be used, it must be configured in the instance script:

  # Set the location of a script which is called by the 
  # JobScheduler Agent to kill a process and it's children.
  #
  SCHEDULER_KILL_SCRIPT=bin/jobscheduler_agent_custom_kill_task.sh
  

Desired Behavior

• The attached jobscheduler_agent_nokill_task.sh script should not try to terminate or kill running tasks but instead should allow any tasks to continue.
• This behavior applies to the situation when an Agent is loosing the connection to a Master or is instructed by the Master to terminate/kill a running task
• Warning: we strongly discourage use of this feature except for rare situations when expert users know exactly what they do, see Delimitation.
  • Therefore users have to download the script from this issue and have to deploy the script individually.
  • Store the downloaded script to the ./bin directory of the Agent and overwrite the existing version of this script.
  • Be aware that re-installing or updating the Agent requires to deploy this version of the script once again.

Delimitation

• This behavior will not be introduced to future JobScheduler releases: if a task continues with an Agent that lost the connection with its Master then
  • the Agent will not report back to the Master the execution result
    • the user has to individually check the task log file from the Agent's logs directory.
    • the JOC Cockpit History view will show a failed status and will not include the task log - even in case that the task completed successfully.
  • this Agent must not be used with a process class that defines an Agent cluster with more than 1 Agent. Typically for an Agent Cluster after inavailability of an Agent Cluster member the Master will switch execution of the task to the next Agent. This will result in double task execution.