Add Durable Task middleware support

Summary

Track adding SDK-level Durable Task middleware support to the Java SDK, aligned with the .NET reference implementation.

Reference spec: https://github.com/microsoft/durabletask-dotnet/blob/feature/durable-task-middleware/doc/cross-sdk-middleware.md
.NET user guide: https://github.com/microsoft/durabletask-dotnet/blob/feature/durable-task-middleware/doc/durable-task-middleware.md
Motivation: https://github.com/Azure/azure-functions-durable-extension/issues/3054

The spec may shift until the .NET v1 implementation is merged. This issue is intended to track the Java design and implementation work so it can follow the same durable middleware contract with idiomatic API names.

Proposed shape

Names are illustrative, not final API commitments.

workerBuilder.useOrchestrationMiddleware((ctx, next) -> {
    if (!ctx.isReplaying()) {
        logger.info("starting orchestration {}", ctx.getInstanceId());
    }

    return next.invoke(ctx);
});

workerBuilder.useActivityMiddleware((ctx, next) -> {
    Optional<Object> cached = cache.tryGet(ctx.getName(), ctx.getInput());
    if (cached.isPresent()) {
        ctx.setResult(cached.get());
        return CompletableFuture.completedFuture(null);
    }

    return next.invoke(ctx);
});

Design points to cover

• Builder-level registration APIs for orchestration and activity middleware.
• Registration ordering: first registered middleware runs outermost and unwinds last.
• Context interfaces that expose durable task name, instance ID, version/parent/tags where available, input, raw input where available, replay state for orchestrations, features, and result after next.
• A feature collection keyed by Class<T> or another type-safe Java abstraction.
• Integration with dependency injection frameworks where present, without requiring a particular DI container.
• Orchestration middleware determinism guidance for replay, including replay-safe logging and avoiding nondurable CompletableFuture/threading usage, wall-clock time, random values, file/network I/O, and mutable process state.
• Activity middleware short-circuiting through an explicit setResult API.
• Host integration pattern for Azure Functions or other hosts to attach invocation context through features instead of durable middleware depending on host middleware internals.

Acceptance criteria

• Orchestration and activity middleware APIs are exposed at the durable worker/builder level.
• Middleware executes in registration order and unwinds in reverse order.
• Orchestration middleware must call next.invoke(ctx) exactly once when completing successfully; missing or duplicate calls are rejected where feasible.
• Activity middleware can call next.invoke(ctx) once or short-circuit only through ctx.setResult(...); duplicate next is invalid.
• Host-specific objects can be passed through features without serialization into durable history.
• Documentation covers replay determinism and the difference between durable middleware and host/Functions middleware.
• Tests cover registration ordering, context population, feature access, orchestration next-call validation, and activity short-circuiting.
• No wire protocol or protobuf changes are required.
• Entity middleware is out of scope for v1.

まず、リンクされているクロス SDK ミドルウェア仕様と .NET ユーザーガイドを読み、その後、この Java SDK の durable worker/builder API を調べます。提案されている orchestration および activity ミドルウェアのエントリポイントを使って、コンテキスト機能と検証ルールを含む設計を対応付けます。列挙された受け入れテスト、ドキュメント、ホスト機能の統合が、wire や protobuf の変更なしに実装されていれば完了です。