Pass workflow inputs to success and failure actions

Is your feature request related to a problem? Please describe.

The way parameters are passed to the workflow onFailure and onSuccess actions has already been clarified for a future Arazzo release.

This improvement can be implemented ahead of that release, as it is non-breaking and provides additional functionality.

Describe the solution you'd like

When the step, success action, or failure action in context specifies a `workflowId`, then all parameters map to workflow inputs. In all other scenarios (e.g., a step specifies an `operationId`), the `in` field MUST be specified.

This functionality needs to be implemented.
A similar behavior already exists for dependsOn workflows, which can serve as a reference.

Also action objects are extended with new parameters property, defining the parameters for the action.

Success Action Object

A single success action which describes an action to take upon success of a workflow step. There are two possible values for the type field:

• end - The workflow ends, and context returns to the caller with applicable outputs
• goto - A one-way transfer of workflow control to the specified label (either a workflowId or stepId)

Fixed Fields

Field Name	Type	Description
name	string	REQUIRED. The name of the success action. Names are case sensitive.
type	string	REQUIRED. The type of action to take. Possible values are "end" or "goto".
workflowId	string	The workflowId referencing an existing workflow within the Arazzo Description to transfer to upon success of the step. This field is only relevant when the type field value is "goto". If the referenced workflow is contained within an arazzo type sourceDescription, then the workflowId MUST be specified using a Runtime Expression (e.g., $sourceDescriptions.<name>.<workflowId>) to avoid ambiguity or potential clashes. This field is mutually exclusive to stepId.
stepId	string	The stepId to transfer to upon success of the step. This field is only relevant when the type field value is "goto". The referenced stepId MUST be within the current workflow. This field is mutually exclusive to workflowId.
parameters	[Parameter Object | Reusable Object]	A list of parameters that MUST be passed to a workflow as referenced by workflowId. If a Reusable Object is provided, it MUST link to a parameter defined in the components/parameters of the current Arazzo document. The list MUST NOT include duplicate parameters. The in field MUST NOT be used.
criteria	[Criterion Object]	A list of assertions to determine if this action SHALL be executed. Each assertion is described using a Criterion Object. All criteria assertions MUST be satisfied for the action to be executed.

Failure Action Object

A single failure action which describes an action to take upon failure of a workflow step. There are three possible values for the type field:

• end - The workflow ends, and context returns to the caller with applicable outputs
• retry - The current step will be retried. The retry will be constrained by the retryAfter and retryLimit fields. If a stepId or workflowId are specified, then the reference is executed and the context is returned, after which the current step is retried.
• goto - A one-way transfer of workflow control to the specified label (either a workflowId or stepId)

Fixed Fields

Field Name	Type	Description
name	string	REQUIRED. The name of the failure action. Names are case sensitive.
type	string	REQUIRED. The type of action to take. Possible values are "end", "retry", or "goto".
workflowId	string	The workflowId referencing an existing workflow within the Arazzo Description to transfer to upon failure of the step. This field is only relevant when the type field value is "goto" or "retry". If the referenced workflow is contained within an arazzo type sourceDescription, then the workflowId MUST be specified using a Runtime Expression (e.g., $sourceDescriptions.<name>.<workflowId>) to avoid ambiguity or potential clashes. This field is mutually exclusive to stepId. When used with "retry", context transfers back upon completion of the specified workflow.
stepId	string	The stepId to transfer to upon failure of the step. This field is only relevant when the type field value is "goto" or "retry". The referenced stepId MUST be within the current workflow. This field is mutually exclusive to workflowId. When used with "retry", context transfers back upon completion of the specified step.
parameters	[Parameter Object | Reusable Object]	A list of parameters that MUST be passed to a workflow as referenced by workflowId. If a Reusable Object is provided, it MUST link to a parameter defined in the components/parameters of the current Arazzo document. The list MUST NOT include duplicate parameters. The in field MUST NOT be used.
retryAfter	number	A non-negative decimal indicating the seconds to delay after the step failure before another attempt SHALL be made. Note: if an HTTP Retry-After response header was returned to a step from a targeted operation, then it SHOULD overrule this particular field value. This field only applies when the type field value is "retry".
retryLimit	integer	A non-negative integer indicating how many attempts to retry the step MAY be attempted before failing the overall step. If not specified then a single retry SHALL be attempted. This field only applies when the type field value is "retry". The retryLimit MUST be exhausted prior to executing subsequent failure actions.
criteria	[Criterion Object]	A list of assertions to determine if this action SHALL be executed. Each assertion is described using a Criterion Object.

To summarize, there should be two possible ways to pass parameters to onSuccess or onFailure actions when an external workflowId is defined:

• Define parameters explicitly for the specific action.
• Map all parameters directly to the workflow inputs.

Describe alternatives you've considered

None.

Additional context

• Allow workflow inputs to be passed in success and failure actions #416

Start by tracing the existing dependsOn workflow parameter handling, then compare it with success and failure actions that reference an external workflowId. Implement the documented explicit-parameter and workflow-input mapping behavior, including the new action parameters property, and verify that both action types pass the expected inputs without using an in field.