Use deployment_build_id as part of key for eager workflow start (#1042)

* Use build_id as key for slot

* Don't pass deployment options into start workflow

* Add test

* Fix build_id comparison for slot_providers, try to reserve a different worker if reservation fails, added a test

* Fix unregister logic, add another test for slot boundary and retrying

* use shuffle for clarity

Author: yuandrew

crates/client/Cargo.toml

@@ -38,6 +38,7 @@ tower = { version = "0.5", features = ["util"] }
 tracing = "0.1"
 url = "2.5"
 uuid = { version = "1.18", features = ["v4"] }
+rand = "0.9.2"
 
 [dependencies.temporalio-common]
 path = "../common"

crates/client/src/lib.rs

@@ -1243,7 +1243,7 @@ pub struct WorkflowOptions {
     pub search_attributes: Option<HashMap<String, Payload>>,
 
     /// Optionally enable Eager Workflow Start, a latency optimization using local workers
-    /// NOTE: Experimental and incompatible with versioning with BuildIDs
+    /// NOTE: Experimental
     pub enable_eager_workflow_start: bool,
 
     /// Optionally set a retry policy for the workflow

crates/client/src/raw.rs

@@ -659,8 +659,7 @@ proxier! {
                                     } else {
                                         temporalio_common::protos::temporal::api::enums::v1::WorkerVersioningMode::Unversioned.into()
                                     },
-                                });
-                            }
+                                });                            }
                             slot = Some(reservation.slot);
                         }
                         None => req_mut.request_eager_execution = false