Create execution strategies for the fanout routing

[nbry]

Description

cornerback currently supports parallel fan-out routing, where incoming events are forwarded to configured downstream destinations while also being processed internally (e.g., stored, validated, inspected) at the same time.

While this model is useful for observability and non-blocking delivery, it does not support scenarios where ordering and control over execution flow are required.

We should introduce configurable execution strategies for routing, allowing users to define how events flow through cornerback and downstream systems.

In particular, we want to support:

1. Parallel Execution (existing behavior)

• Event is delivered to all destinations concurrently
• cornerback processing (storage, validation, etc.) happens independently
• Failures in one destination do not block others

2. Serial Execution (new)

• Event flows through a defined sequence of steps
• Example:

Incoming Event → cornerback (validation/processing) → Production API

• Enables:
• Validation before delivery
• Transformation before forwarding
• Conditional routing based on processing results

This feature allows cornerback to move beyond simple fan-out and act as a controlled event pipeline, giving users fine-grained control over how and when events are delivered.

Acceptance Criteria

• Introduce a configurable execution strategy for routing:

• parallel (default, existing behavior)

• serial (new)

• Define a routing pipeline abstraction that supports ordered execution of steps

• In serial mode:

• Events must pass through cornerback processing (e.g., validation, transformation) before being forwarded

• Downstream delivery should only occur if prior steps succeed (configurable behavior)

• Ensure parallel mode remains unchanged and backward compatible

• Allow configuration per webhook ID (or equivalent source):

routing:
  strategy: serial
  steps:
    - validate
    - transform
    - forward: http://api

• Support failure handling strategies in serial mode:
  • Stop on failure (default)
  • Continue on failure (optional, configurable)
  • Route to DLQ on failure
• Ensure observability:
  • Log execution path per event
  • Capture success/failure at each step
  • Expose execution details via API
• Maintain compatibility with replay system:
  • Replayed events should respect the configured execution strategy
• Provide at least one example demonstrating:
  • Serial validation before forwarding to a production endpoint
  • Parallel fan-out to multiple destinations
  • Document differences between execution strategies and when to use each