Investigate Python SDK concurrency limitations

The Python Dapr SDK currently relies on threadpool-based execution for workflow and activity processing. This model has known limitations:

* The GIL (Global Interpreter Lock) constrains true parallelism for CPU-bound work
* Thread pool exhaustion under high concurrency can delay sidecar acknowledgments

Native asyncio execution would allow the SDK to handle a higher volume of concurrent workflow tasks without the overhead and contention introduced by thread management, reducing sidecar response latency under sustained load.

Goals

* Quantify the throughput and latency characteristics of the current threadpool implementation under sustained workflow load
* Rewrite workflow and activity execution to use native asyncio
* Validate that the rewrite improves sidecar response latency and throughput under load conditions

Tasks

- [X] Benchmark current threadpool implementation — measure workflow throughput, activity concurrency, and sidecar acknowledgment latency under sustained load
- [X] Document failure conditions — identify load thresholds at which sidecar response times begin to degrade
- [X] Design asyncio execution model — propose the replacement architecture for workflow and activity dispatch
- [X] Implement asyncio rewrite — replace threadpool-based execution with native asyncio in the workflow worker
- [X] Ensure existing workflow and activity behavior is preserved
- [X] Load validate — re-run benchmarks against the rewritten implementation under production-representative load and confirm improvement in sidecar response latency and throughput
- [X] Document operational guidance — update SDK documentation with concurrency configuration recommendations for workflow-heavy deployments
- [ ] Write Dapr OSS blog on findings