Support try-catch for both invoke and run

[KiKoS0]

Summary

If an exception is thrown in the invoke or run function, it will now
be caught and returned as a StepError exception. This will allow the
error to be propagated to the caller and handled appropriately.

Transforming the errors into a StepError exception is following the
SDK spec:
https://github.com/inngest/inngest/blob/main/docs/SDK_SPEC.md#522-memoizing-a-step
JS SDK behavior:
https://github.com/inngest/inngest-js/blob/4f91d9c302592ecc2228914469dd057ae148005b/packages/inngest/src/components/execution/v1.ts#L437-L443
Docs:
https://www.inngest.com/docs/features/inngest-functions/error-retries/inngest-errors#step-errors

StepError is a RuntimeException which means that it can be used in Java code without needing to change the interface of Inngest.execute to introduce checked exceptions or break existing step.run & step.invoke calls by requiring strict handling of the exception.

Usage

Invoke

try {
    step.invoke<Map<String, Any>>(
        "send-email",
        "ktor-dev",
        "Email",
        mapOf("email" to "[email protected]"),
        null,
    )
} catch (e: StepError) {
    // Handle error
}

Run

try {
    step.run("send-email") {
        // Run the step
    }
} catch (e: StepError) {
    // Handle error
}

Changes:

• Create a StepError exception that users can catch to handler errors.
• Add try/catch support for step.run.
• Add try/catch support for step.invoke.
• Implement example Kotlin functions demonstrating the usage.
• Implement integration tests for them.

Checklist

• Update documentation
• Added unit/integration tests

Related

• INN-3330

[linear]

INN-3330 Support (or confirm support) for try/catch of steps

[albertchae]

nice, let's double check whether avoiding checked exceptions is desired and iterate post merge if necessary

[albertchae]

wonder if it's worth pulling out this set as a constant, maybe calling it something like "terminal" status codes? Fine to leave as is if other SDKs aren't doing that

[albertchae]

similar comment as the set of ResultStatusCodes, but again not worth doing if other SDKs aren't

[albertchae]

you can remove this now that #67 is merged right?