[SGunner2014]

Description

This adds an optional taskQueue property to the run.workflow schema. If defined, then the new workflow will run on the task queue specified. Otherwise, it will default to the parent's task queue as is the current behaviour.

This PR updates the schema validation only, runtime support will be handled separately.

Related issue

Relates to zigflow/zigflow#556

How to test

Run the focused schema tests:

go test -run 'TestRunWorkflowTaskQueueProperty|TestSchema_RunWorkflowTaskQueue' -v ./...

Start a workflow with a workflow step configured with a custom taskQueue:

document:
  dsl: 1.0.0
  workflowType: order-orchestrator
  taskQueue: orchestration-queue
  version: 1.0.0
 
do:
  - processOrder:
      run:
        workflow:
          type: order-processing
          taskQueue: orders.v2
          input:
            orderId: ORD-123

The child workflow should then be triggered on the task queue orders.v2.

Checklist

• This PR links to an issue using Fixes #..., Closes #... or Relates to #...
• All tests pass
• Tests have been added or updated where behaviour changed
• Documentation has been updated where needed

[YJ-928]

Thanks @SGunner2014, this looks good: optional, additive, and named like the other run.workflow fields, and CI is green. Approving.

Two small things, neither blocking:

• 64-character name is accepted reads as if there were a 64-character limit, but the schema sets no maximum. I'd drop that case or rename it.
• The commit shows as unverified on GitHub (unknown_key). It doesn't block this repo, but zigflow/zigflow requires verified signatures, so add the signing key to your GitHub account before the runtime PR.

For the follow-up runtime PR in zigflow/zigflow (nothing to change here):

• Say whether taskQueue is a plain string or can be a runtime expression (${ ... }). If expressions are allowed, it needs to be evaluated before the child starts, plus a test.
• Nothing can check that a worker polls that queue, so the child would sit pending. A line in the run.workflow docs saying a worker must listen on that queue would save people a confusing wait.

I'll merge in a day or two so you can fold in the first point if you want; it's fine as is otherwise.

[SGunner2014]

@YJ-928 Thanks, makes sense. I've updated the PR to remove this test case and have added a signing key for future changes.

[YJ-928]

Thanks @SGunner2014, all good. Merging. Looking forward to the runtime PR in zigflow/zigflow.