feat: QdrantServerless client prototype

[qdrant-cloud-bot]

Summary

Prototype of a dedicated client for Qdrant Serverless, parallel to the regular Qdrant client, following the serverless client design and mirroring qdrant-client#1393.

use qdrant_client::serverless::{
    CollectionConfig, DenseVectorConfig, Distance, QdrantServerless,
};

let client = QdrantServerless::from_url("https://serverless....qdrant.io")
    .api_key("...")
    .build()?;

client
    .create_collection(
        "my-collection",
        CollectionConfig::new()
            .dense_vector(DenseVectorConfig::new(1536, Distance::Cosine)),
    )
    .await?;

client.get_collection("my-collection").await?; // serverless-specific output
client.query(QueryPointsBuilder::new("my-collection").query(vec![...])).await?;

Why

Serverless is not identical to a regular cluster: collection management exposes only a simplified tenant-facing config (no quantization/WAL/segments), and point operations don't support read consistency, shard selection, write ordering, or filtered updates. A separate client keeps those parameters out of the serverless interface.

How (Rust adaptations)

Everything lives in a dedicated qdrant_client::serverless module.

• gRPC stubs generated from qdrant-cloud-public-api's serverless/collections.proto into src/serverless/grpc.rs (crate-private). Sync/regenerate with tools/sync_serverless_proto.sh / cargo test --test serverless_protos -- --ignored.
• Models: hand-written public types (DenseVectorConfig, SparseVectorConfig, PrecisionTier, payload-index types, CollectionConfig, CollectionInfo, CollectionSummary) — no storage internals. Generated gRPC types stay internal.
• Client: QdrantServerless wraps an internal Qdrant (check_compatibility = false) and reuses its channel for both PointsService and the new CollectionsService (TLS, api-key metadata, user-agent in one place).
  • Point methods accept the regular builders/request types but clear unsupported fields (read_consistency, shard_key_selector, ordering, lookup_from, with_lookup, update_filter, update_mode) before the RPC — Rust's shared builders can't drop fields from the type system without a full parallel builder set.
  • Collection methods use the tenant-facing config API; get_collection returns CollectionInfo { exists, ... } instead of erroring on missing collections.
  • URLs without an explicit port default to 443 (not 6334).
• No separate async client: the Rust client is already async (unlike Python's sync/async split).

Not included (mechanical follow-ups)

Dedicated builders that omit unsupported fields at the type level; live integration tests against a serverless endpoint.

Test plan

• cargo test --lib serverless
• cargo test --test serverless_protos
• cargo clippy --lib -- -D warnings
• cargo check --example serverless --features serde
• Live run against a serverless space (manual)

[qdrant-cloud-bot]

Documented the serverless client as in development — do not use yet in module/crate docs, QdrantServerless, models, and the example.

[timvisee]

We can probably remove this (for now), as we don't support custom deployments.