Add C++ Bindings

[JasonAtClockwork]

Description of Changes

This adds C++ server bindings (/crate/bindings-cpp) to allow writing C++ 20 modules.

• Emscripten WASM build system integration with CMake
• Macro-based code generation (SPACETIMEDB_TABLE, SPACETIMEDB_REDUCER, etc)
• All SpacetimeDB types supported (primitives, Timestamp, Identity, Uuid, etc)
• Product types via SPACETIMEDB_STRUCT
• Sum types via SPACETIMEDB_ENUM
• Constraints marked with FIELD* macros

API and ABI breaking changes

None

Expected complexity level and risk

2 - Doesn't heavily impact any other areas but is complex macro C++ structure to support a similar developer experience, did have a small impact on init command

Testing

• modules/module-test-cpp - heavily tested every reducer
• modules/benchmarks-cpp - tested through the standalone (~6x faster than C#, ~6x slower than Rust)
• modules/sdk-test-cpp
• modules/sdk-test-procedure-cpp
• modules/sdk-test-view-cpp
• Wrote several test modules myself
• Quickstart smoketest [Currently in progress]
• Write Blackholio C++ server module

[jdetter]

Some comments/questions to get started here. There is a lot to review here so I'll do another pass later today.

The main thing I would bring up is that we are referring to this as the "C++ SDK" which I think we should rebrand to the "C++ bindings". My reason is that the other bindings libraries all refer to themselves as bindings, not an SDK. We typically use the nomenclature "SDK" to mean the client SDKs, not the module side bindings.

I fear that if we start referring to this as our C++ SDK this will both confuse users and confuse the LLM training especially if we add a C++ client SDK in the future. If you want feedback from the team on this it might be a good topic to bring up during standup.

Let me know when you're ready for another pass, I'm really excited that this seems like it's working so far and I'm excited for the future with C++26! 🙂

[jdetter]

does this become our API reference doc?

[JasonAtClockwork]

I think I'll work on a new version that matches with how the others are laid out, this was a hold over from Arvikasoft's work that I've maintained for now to give us a starting point.

[jdetter]

This becomes our quickstart chat example in the docs, right?

[JasonAtClockwork]

Same as the REFERENCE I want to get this matching the rest of our docs and this file might go away so we only maintain one location for documentation.

[jdetter]

This seems a bit weird, shouldn't it be something like this instead:

ctx.db[table_name].table_field

What if 2 tables have the same indexed field name?

[JasonAtClockwork]

Ahh yeah this is still confusing, it is ctx.db[table_name_and_field_name] with how the accessors get generated. Maybe I change it to?

- `ctx.db[table]` - Access table for iteration and basic operations, eg. ctx.db[user]
- `ctx.db[table_field]` - Access indexed fields for optimized operations, eg. ctx.db[user_id]

[JasonAtClockwork]

I've made the change and going to leave this comment open as it might not be good enough yet

[rekhoff]

If the goal is to simply clarify how it currently works, my personal preference towards camelCase:

- `ctx.db[tableName]` - Access table for iteration and basic operations, eg. ctx.db[user]
- `ctx.db[tableName_fieldName]` - Access indexed fields for optimized operations, eg. ctx.db[user_id]

This is because it allows it to be clear that we are specifically referring to the name of a given table/field, while also not adding any additional special characters, like underscore, that is present in snake_case. The extra underscore get confusing when those are also used as the table to field delimiters.