feat(cpp): part of low-level bindings, their tests, and e2e CI config

[slbotbm]

Which issue does this PR close?

Add part of low-level bindings for iggy-hpp.

Works towards completion of #2763 .

Rationale

To be merged after #2785

What changed?

Adds low-level bindings + tests + e2e CI config. The following functions have been added for the Client opaque type:

• new_connection (equivalent to Rust's IggyClientBuilder::new() and IggyClient::from_connection_string(connection_string))
• login_user
• connect
• create_stream
• get_stream
• delete_stream
• create_topic
• delete_connection

tests/client/low_level_e2e.cpp -> e2e tests for client
tests/topic/low_level_e2e.cpp -> e2e tests for topic
tests/stream/low_level_e2e.cpp -> e2e tests for stream

NOTE: The PR is big since Cargo.lock itself is 5k LoC. The actual code itself is about 1k LoC.

Local Execution

• Passed
• Pre-commit hooks ran

AI Usage

If AI tools were used, please answer:

1. Which tools? codex
2. Scope of usage? code generation
3. How did you verify the generated code works correctly? Planned what needs to be implemented, created spec, and then verified all code generated and tests run.
4. Can you explain every line of the code if asked? Yes

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 70.26%. Comparing base (ff4716e) to head (9273c28).
⚠️ Report is 1 commits behind head on master.

Additional details and impacted files

@@             Coverage Diff              @@
##             master    #2852      +/-   ##
============================================
- Coverage     70.28%   70.26%   -0.03%     
  Complexity      862      862              
============================================
  Files          1028     1028              
  Lines         85280    85280              
  Branches      62656    62666      +10     
============================================
- Hits          59940    59921      -19     
- Misses        22828    22838      +10     
- Partials       2512     2521       +9     

Flag	Coverage Δ
csharp	67.43% <ø> (-0.19%)	⬇️
go	36.36% <ø> (ø)
java	59.87% <ø> (ø)
node	91.37% <ø> (-0.17%)	⬇️
python	81.43% <ø> (ø)
rust	70.64% <ø> (-0.02%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.
see 9 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[amlel-el-mahrouss]

Hey, I'm looking at it right now! Feel free to @ me on Discord as well.

[slbotbm]

This PR is ready for review.

[amlel-el-mahrouss]

@slbotbm Here's my review:

What's good:

• Separation of concerns is good. (Using FFI, and Rust)
• Every unit has a clear purpose and does it well.
• Testing coverage is here. (Using GTest!)

Additional questions:

• Why not instead of:

        ffi::Identifier {
            kind,
            length: identifier.length,
            value: identifier.value,
        }

why not: identifier.make_ffi(kind)?

[hubcio]

i also noticed that CompressionAlgorithm, Expiry, MaxTopicSize, PollingStrategy, IdKind aredefined and unit-tested, but the e2e tests pass raw strings directly. any reason for that?

[slbotbm]

i also noticed that CompressionAlgorithm, Expiry, MaxTopicSize, PollingStrategy, IdKind aredefined and unit-tested, but the e2e tests pass raw strings directly. any reason for that?

I had intended for those structs to be used in the high-level client. Would it be better to use them for the low-level client also? (but in the future we will be defining the stubs for the high-level client's api in iggy.hpp, so including iggy.hpp in the low level client will lead to confusion.)

[slbotbm]

@slbotbm Here's my review:

What's good:

* Separation of concerns is good. (Using FFI, and Rust)

* Every unit has a clear purpose and does it well.

* Testing coverage is here. (Using GTest!)

Additional questions:

* Why not instead of:

        ffi::Identifier {
            kind,
            length: identifier.length,
            value: identifier.value,
        }

why not: identifier.make_ffi(kind)?

@amlel-el-mahrouss I didn't understand the question. There is no "make_ffi" function defined, as far as I know.

[amlel-el-mahrouss]

@slbotbm Hey, so I was proposing a make_ffi function, which would make the code DRY.
Let me know what you think about it.

[slbotbm]

@amlel-el-mahrouss I did not create a function like make_ffi since that is not a helpful abstraction. If a person other than you or me looks at the code, they will have difficulty understanding the code just from looking at make_ffi. I do not deny that abstractions are required (I utilize rust's From trait to convert from and to ffi), but I feel that these abstractions are discovered after spending a significant amount of time developing and refactoring the code. Pre-mature abstractions lead to difficulty in maintaining and understanding the code.

[amlel-el-mahrouss]

@slbotbm That's a fair assessment, yes let's not pre-optimize the code before it lands in production, thank you for that comment.