ClientWorkload bindings unstable ABI

[Eloi Démolis]

The ExternalWorkload of foundationdb allows to load client compiled shared object as workloads in the FoundationDB simulation. This can be used to load layers written in other languages as long as it can be compiled to a shared object and binds on ClientWorkload.h API.

The use of C++ for the workload bindings makes the ABI dependent on the compiler and standard library used to compile the fdbserver.
This proved to be an issue and became apparent in our integration of the foundationdb-rs simulation, where transitioning from version 7.1 to 7.3 resulted in sudden crashes (segmentation faults). The cause, as detailed in a forum post, was attributed to the compiler switch from gcc to clang, altering the memory representation of a std::string.

Beyond the immediate risk of breakage, the need to meticulously reproduce the compilation environment for the entire project just to ensure workload integration is quite burdensome.

Moreover, the reliance on C++ for cross-language integration presents limitations. While there are options like Zig, Java with JNI, and potentially Carbon, all other languages must develop their own wrapper to interface with the simulation. This convoluted process of C++ -> C -> Language -> C -> C++ adds unnecessary complexity and overhead.

It would be far more straightforward if FoundationDB exposed C bindings directly. This approach would stabilize the ABI, reduce compilation environment requirements, and foster greater interoperability across diverse language ecosystems.

To ensure compatibility with currently developed workloads (mainly the JavaWorkload), retaining the C++ bindings could be considered. However, alongside this, making C bindings available as an alternative would offer a more versatile solution. This approach would provide developers with the flexibility to choose between C and C++ bindings based on their specific requirements, while still addressing the challenges of stability and integration across different language ecosystems.