Add synchronous join support to FORK_JOIN (#619)

[nthmost-orkes]

Implements #619 - adds property-based control for synchronous vs asynchronous join behavior in FORK_JOIN tasks.

Implementation

Property-Based Control

• Added joinMode property to WorkflowTask (values: "SYNC" or "ASYNC")
• Property is optional; defaults to "ASYNC" for backward compatibility
• Passed through JoinTaskMapper to join task input data

Synchronous Behavior via Evaluation Offset

Rather than overriding isAsync() (which doesn't support per-task control), synchronous behavior is achieved through the evaluation offset mechanism:

• SYNC mode: Returns 0 evaluation offset → join is evaluated every workflow decision cycle
• ASYNC mode (default): Uses exponential backoff → join is polled with increasing delays

This approach works within the existing framework constraints while providing responsive synchronous-like behavior.

Usage Example

{
  "name": "join_task",
  "taskReferenceName": "join_ref",
  "type": "JOIN",
  "joinOn": ["task1", "task2"],
  "joinMode": "SYNC"
}

Backward Compatibility

• Existing workflows without joinMode continue using async behavior
• No breaking changes to APIs or existing functionality

Tests

• Unit tests for both sync and async modes
• JoinTaskMapper tests verify property passing
• All existing tests continue to pass

Convergence Notes: OSS vs Orkes Implementation

Current Orkes Implementation (OrkesJoin)

Orkes Conductor replaces the OSS Join component entirely with OrkesJoin:

• Always synchronous: isAsync() = false - no property-based control
• Wraps OSS Join: Internally delegates to OSS Join for basic functionality
• Additional features:
  • Script-based join conditions via expression and evaluatorType (GraalJS)
  • Large fork optimization (conditional output capture for 500+ tasks)
  • Enhanced execution logic with custom evaluators

Convergence Path Options

Option 1: Orkes adopts OSS property-based approach

• Replace OrkesJoin with enhanced OSS Join + property control
• Set joinMode: "SYNC" by default in Orkes for backward compatibility
• Keep Orkes-specific features (expressions, large fork optimization) as separate enhancements
• Benefit: Shared core, easier maintenance

Option 2: Keep separate implementations

• OSS: Property-based sync/async control
• Orkes: Always-synchronous with advanced features
• Both implementations continue to coexist
• Benefit: No migration needed, each optimized for use case

Implementation Compatibility

This PR's approach is convergence-friendly:

• ✅ Additive (new optional property)
• ✅ Non-breaking (defaults to async)
• ✅ Framework-aware (uses evaluation offset, not isAsync override)
• ✅ Orkes can layer expression support on top of property-based control

The property-based approach could serve as foundation for future convergence if Orkes wants to support both sync and async modes with user control.

[nthmost-orkes]

Update on convergence: Replaced the offset=0 approach with isAsync(TaskModel task) on WorkflowSystemTask — this brings OSS Join much closer to OrkesJoin than we had before when we were avoiding changing the WorkflowSystemTask API

	OSS Join (now)	OrkesJoin
Sync execution	isAsync(task) = false when joinMode=SYNC — runs in decide thread	isAsync() = false always
Per-task control	✅ user-controlled via joinMode	❌ always sync
Script conditions	❌	✅ (expression + GraalJS)
Large fork optimization	❌	✅ (500+ tasks)

Convergence path for Orkes is now simple: subclass OSS Join, override isAsync(TaskModel task) to return false unconditionally — no workflow definition changes or migrations needed. Orkes-specific features (GraalJS, large fork optimization) layer on top as before. The joinMode enum also gives Orkes a path to expose user-controlled sync/async in the future.