enhance: Support idempotent broadcast, with BulkImport as its first user
The Issue & Context
Orchestrators like Airflow or Temporal retry import jobs after a crash occurring post-acceptance but pre-persistence of the jobID, causing duplicate import jobs and data duplication in Milvus.
Root Cause Analysis
Retries of the same import files generate new jobIDs because there was no idempotency mechanism on the broadcast path to correlate repeated requests with the original job.
Solution Strategy & Architectural Pattern
Implemented a generic idempotency mechanism on the broadcast path that carries a client-supplied idempotency key scoped by message type and collection ID, enabling retries to resolve to the original jobID without duplicating data. This was applied first to BulkImport and designed to be transport-agnostic with no changes to protobufs.
Key Takeaway for Contributors
Introducing scoped idempotency keys at the broadcast layer prevents duplicate job creation on retries, handles renames and recreations gracefully by scoping to immutable IDs, and provides a reusable pattern for other broadcast message types to achieve idempotent operations.