Add ability in task spec to wait for a lock before proceeding

There are use cases where users want to synchronize access to a resource (i.e. server) across multiple and different workflow executions. Currently, StackStorm offers concurrency policies to synchronize executions for one given workflow.

The following proposal allows specification of the lock requirement across different workflow definition so synchronization is possible against different workflow executions on the same resource(s). In the proposal below, a new wait attribute is introduced to the task spec. The wait attribute takes the name of the lock, which can be a unique name or name of the resource. The task will sleep/delay until the lock is acquired. On exit from the task scope, the lock will be released.

An additional wait delay can be specified. If the lock is not acquired within the wait period, the task will abandon the wait and exit with failure. On failure, the task transition will be traversed as normal so that clean up or retry is possible.

tasks:
  task1:
    wait: <% ctx().resource_lock_name %>
    action: ...

tasks:
  task1:
    wait:
      lock: <% ctx().resource_lock_name %>
      delay: 600
    action: ...

The mechanism will require on external platform such as redis which is currently already being used for various use cases in StackStorm (required for concurrency policies and running complex branching workflows, etc.).

Start with the task spec and existing concurrency policies, then trace how workflow executions use Redis. Define how the wait lock and optional delay interact with task scope, failure transitions, retries, and lock release. Done means different workflow executions can synchronize on a named resource and abandon the wait with normal failure handling when the delay expires.