cosmos: add experimental c wrapper around cosmos sdk

[analogrelay]

This is a bit of an experiment, but I'm game to merge it if @heaths and other Cosmos folks like it.

We want to explore the option of publishing a C library of the Azure Cosmos DB SDK for Rust. This PR adds the basic framework to start that effort:

• A new package cosmosclient that depends on azure_data_cosmos. This package builds a cdylib and staticlib target (libcosmosclient.a/libcosmosclient.so/cosmosclient.dll/etc.) that exports a C-compatible API. For now, that API is extremely simple (cosmosclient_version).
• A simple test infrastructure (NOT currently integrated into anything). There are C programs in sdk/cosmos/cosmosclient/c_tests that will be built and linked against the cosmosclient library. The tests are simple pass/fail programs. If the test returns a 0 exit code, it passed, otherwise, it failed.
• build.rs script in cosmosclient to produce sdk/cosmos/cosmosclient/include/cosmosclient.h, which is a C header file defining the API surface of cosmosclient. We should publish this as an artifact at some point, but for now it's there to be used by tests.

[Copilot]

Pull Request Overview

This PR adds an experimental C wrapper around the Azure Cosmos DB SDK for Rust, introducing a new cosmosclient package that exports a C-compatible API. The goal is to explore publishing a C library version of the Cosmos DB SDK.

Key changes:

• New cosmosclient crate that builds both static and dynamic C libraries
• C header generation using cbindgen with version information
• Basic C test infrastructure using CMake for validation

Reviewed Changes

Copilot reviewed 10 out of 11 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
sdk/cosmos/cosmosclient/src/lib.rs	Core library implementation with C-compatible API and version function
sdk/cosmos/cosmosclient/Cargo.toml	Package configuration for building C libraries (cdylib/staticlib)
sdk/cosmos/cosmosclient/build.rs	Build script for generating C headers and build identifiers
sdk/cosmos/cosmosclient/CMakeLists.txt	CMake configuration for C test compilation and linking
sdk/cosmos/cosmosclient/c_tests/version.c	C test program to validate version consistency
sdk/cosmos/azure_data_cosmos/Cargo.toml	Added "c" feature for exposing additional types to C wrapper
Cargo.toml	Added cosmosclient to workspace members

[LarryOsterman]

Just two minor nits.

[LarryOsterman]

possibly cosmos_c_client for disambiguation?

[analogrelay]

I agree it's a little bit ambiguous.

The problem is that the name field determines the name of the output library (not just the file name, but also internal metadata in the library files themselves) and there doesn't appear to be a way to change that. Though I may be able to do something by explicitly specifying the [lib] target 🤔 let me give that a shot.

[analogrelay]

Ok, that works. package.name and lib.name can be different, the former determines the name of the package for things like cargo build --package and the latter determines the output binary name.

[LarryOsterman]

This is a 100% style nit, but I generally prefer putting attributes after the rustdoc comment - since the attributes bind to the function I like putting them as close to the function declaration as I can.

Putting them before the rustdoc comment leads me to forget they exist :).

[analogrelay]

That totally makes sense, I agree.

[analogrelay]

/azp run rust - pullrequest

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[heaths]

The vcpkg issue should be fixed now after #3076 but you also have a problem the Analyze step found:

Caused by:
  failed to parse manifest at `/mnt/vss/_work/1/s/sdk/cosmos/azure_data_cosmos_native/Cargo.toml`

Caused by:
  error inheriting `cbindgen` from workspace root manifest's `workspace.dependencies.cbindgen`

Caused by:
  `dependency.cbindgen` was not found in `workspace.dependencies`

[heaths]

/azp run rust - pullrequest

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[heaths]

You'll need to rebase again. There was some breaking change in eng/common that went in and is fixed for JS and Rust. That said, there are still some analysis errors. I'm also concerned that you use a specific version in build-dependencies and should've been flagged. We generally don't allow that in eng/scripts/verify-dependencies.rs. We catch those normally. I'd rather make sure all versions are consistent at time of release.