feat(cpp): Create initial client

[slbotbm]

Which issue does this PR close?

Closes #2100

Rationale

This PR implements a blocking c++ client using CXX. I'll open a discussion on the design by the weekend. The discussion can be seen at #2691 . Tests/CI scripts haven't been added yet. After the design is finalized, I'll add them.

What changed?

Deletes the old incomplete client. Adds a client that uses cxx to generate rust -> cpp bindings. examples/example.cpp has been temporarily included to show how the public API would look like. instructions on running it are included in README.md.

Local Execution

• Passed
• Pre-commit hooks ran

AI Usage

1. OpenAI Codex, Google Gemini
2. Writing code, and reviewing. I planned everything out and made the AI write the code.
3. Read through it multiple times and verified the output to the best of my abilities.
4. I can explain about 95% of the code.

[slbotbm]

An integration test from connectors is failing, which is unrelated to the changes I made.

[hubcio]

@slbotbm this is toggler test, i re-ran you tests. I'll fix this toggler today.
EDIT: toggler should be fixed once #2667 is merged.

[hubcio]

@slbotbm couple of questions from my side:

1. could you please delete old cpp SDK in one PR, and add yours is another? just to make it easier for me to review it.
2. did you build it with clang or gcc? will it work with both?
3. what would be your next steps, assuming we'll merge it as-is? do you have any plans for event loop?

I didn't review the code yet, I just skimmed thru it.

[slbotbm]

@hubcio

Thanks for your questions.

1. done
2. From what i understand, bazel uses the existing toolchain on the user's computer, as long as the toolchain supports c++17. Thus, it can be built with both
3. I had hoped to make this + the python client complete by adding all of the features in other non-ffi clients. What do you mean by event loop?

On a side note, the connectors' quickwit integration tests are failing.

[hubcio]

Tests should now pass, i merged #2667 and rebased your PR. Regarding 3: event loop - the current design calls RUNTIME.block_on() for every operation, so every C++ call blocks until the async Rust code finishes. That works fine for simple use cases, but for anything high-throughput (continuous polling, concurrent sends), users would need threads on the C++ side to work around it. So, my rephrased question is:
do you have any plans to expose async APIs (callbacks, futures, or letting users drive the runtime), or is blocking the intended final design?

I'm fine with either, just keep in mind that at some point in future we want to add proper sans-io based Rust SDK.

[hubcio]

Just to add, python sdk uses pyo3 async runtimes, where we convert from Rust futures to python coroutines:

    #[gen_stub(override_return_type(type_repr="collections.abc.Awaitable[None]", imports=("collections.abc")))]
    fn ping<'a>(&self, py: Python<'a>) -> PyResult<Bound<'a, PyAny>> {
        let inner = self.inner.clone();
        future_into_py(py, async move {
            inner
                .ping()
                .await
                .map_err(|e| PyErr::new::<pyo3::exceptions::PyRuntimeError, _>(format!("{e:?}")))
        })
    }

EDIT: if you require C++20 you can use https://github.com/pcwalton/cxx-async so you'll be able to call co_await Rust futures directly, which is pretty neat in my opinion

EDIT 2: also check https://cxx.rs/async.html

EDIT 3: also check https://github.com/mozilla/uniffi-rs + https://github.com/NordSecurity/uniffi-bindgen-cpp

[slbotbm]

Thank you for the explanation. The part about the event loop was something I had wanted to explain in the design, so please allo me time until Friday-Saturday to create the discussion.

[hubcio]

@slbotbm no problem, take your time. it's not easy topic :)

[slbotbm]

@hubcio
I've been looking into making the cpp client async. As I'd stated on discord, uniffi-rs and the related cpp version do not suport async operations so I'm not considering them. Between using cxx-async, and the method mentioned in https://cxx.rs/async.html, I am leaning more towards using cxx-async. This is because without using cxx-async, we would have to manage the locks, atomic states, and callback rules by ourselves, which could result in errors. cxx-async takes care of this to a certain extent, so the risk of erroring is less.

With regards to the design, I'd like to keep the sync version to support C++17, and write additional code for the async version that will use C++20.