[One Workflow][Custom steps] Async conditional registration

[semd]

Summary

From: #259159

Enables conditional async registration of workflow custom steps on both the public and server side of the workflows_extensions plugin.

• registerStepDefinition now accepts a sync definition or an async loader (() => Promise<Definition | undefined>). A loader resolving to undefined is a no-op, so plugins can gate registration behind async checks (e.g. feature flags, license, capabilities) without an explicit branch around the call.
• Adds isReady() to the shared WorkflowsExtensionsStartContract (already present on the public start; now also on the server start). It resolves once every pending async loader has settled.
• Loader rejections — and any error thrown while inserting the resolved definition into the registry — are caught and logged via the plugin logger as Failed to register step definition with the original error attached as meta. They do not propagate, so a single broken loader cannot break other steps or workflow execution as a whole. Consequently, isReady() always resolves; consumers can await it without try/catch.
• The execution engine setupDependencies awaits workflowsExtensions.isReady() before reading the workflow execution, so step handlers registered asynchronously are guaranteed to be available when the engine runs.
• Both PublicStepRegistry and ServerStepRegistry now take a Logger in their constructor, wired from the corresponding plugin's initializerContext.logger.get().

Changes

• workflows_extensions/common/types.ts — add isReady(): Promise<void> to WorkflowsExtensionsStartContract.
• workflows_extensions/public/step_registry/step_registry.ts — accept loader, skip on undefined, log loader/registration errors via the injected Logger.
• workflows_extensions/server/step_registry/step_registry.ts — same async/loader behavior + whenReady(), takes a Logger in the constructor.
• workflows_extensions/server/plugin.ts — expose isReady() from start; accept ServerStepDefinitionOrLoader in registerStepDefinition; pass the plugin logger to ServerStepRegistry.
• workflows_extensions/public/plugin.ts — pass the plugin logger to PublicStepRegistry.
• workflows_extensions/public/types.ts & server/types.ts — types for the new loader signature; move isReady() into the shared start contract.
• workflows_extensions/server/mocks.ts — add isReady to the start mock.
• workflows_extensions/dev_docs/STEPS.md — document async + conditional registration on both sides, the log-don't-throw error model, and the server-side isReady().
• workflows_execution_engine/server/execution_functions/setup_dependencies.ts — await workflowsExtensions.isReady() before fetching the workflow execution.

Test plan

• Unit tests updated/added for both registries (sync, async loader, undefined-skip, mixed sync/async, duplicate handling via async loader, loader rejection — all assert that whenReady() resolves and that logger.error is called with the original error).
• Unit tests added for setupDependencies covering: it awaits isReady() before reading the execution, and propagates errors thrown by isReady().
• All affected Jest suites pass locally.

[yngrdyn]

LGTM 🚀

[elasticmachine]

⏳ Build in-progress, with failures

• Buildkite Build
• Commit: 41f56b6

Failed CI Steps

• Check Types

History

• 💔 Build #431902 failed f1aab25

cc @semd