feat(convention): Implement convention to render cpp workers compatible with other sdk clients

[jfonseca-aneo]

Summary

This PR implements the task options convention for the C++ SDK, enabling interoperability with other ArmoniK SDK clients. It adds a new execution path in the DynamicWorker alongside the existing legacy path, extends the client to submit convention-encoded tasks and upload shared libraries as blobs, and introduces a TaskDefinition API that handles blob (task inputs) upload automatically.

Context: Convention definition

The convention is an agreed encoding that allows a client written on top of any the supported SDKs to submit tasks to a worker written on top of any of the supported SDKs (Java, C#). In concrete terms:

• Task options keys — ConventionVersion, LibraryPath, LibraryBlobId, Symbol — carried in the flat TaskOptions.options map, following the same keys used by the C# and Java SDKs.
• Payload format — a JSON envelope {"inputs":{...},"outputs":{...}} replacing the C++-specific binary encoding for convention tasks.

The DynamicWorker selects the path at runtime: presence of ConventionVersion in task options triggers the convention path; its absence falls through to the unchanged legacy path.

Context: Blobs

A blob is a named, immutable byte sequence stored in ArmoniK's result storage and identified by a UUID. The concept and the terminology are borrowed from the C# and Java SDKs, where blobs are the standard unit for passing data between clients and workers. In the convention path, task inputs and the worker library are all transmitted as blobs: the client uploads them before submission, lists their IDs in data_dependencies, and the worker downloads them at execution time. This is in contrast to the legacy C++ path, where the payload is embedded directly in the task submission request.

Main changes

• ArmoniK.SDK.Common: new DynamicLibrary struct with convention key constants; TaskPayload (the legacy binary format) is marked [[deprecated]] — use TaskDefinition with Submit(vector<TaskDefinition>) instead; an internal ConventionPayload struct carries the JSON wire format for the convention path — it lives in armonik/sdk/common/internal/ConventionPayload.h and is not part of the public API; TaskOptions gains SetDynamicLibrary / GetDynamicLibrary / GetConventionVersion helpers.

• ArmoniK.SDK.DynamicWorker: convention path added to DynamicWorker::Execute() — handles blob-based library loading, method name fallback from task options, and transparent input blob resolution. ApplicationManager gains UseLibrary() for loading a .so directly by path with a configurable symbol prefix.

• ArmoniK.SDK.Client: new UploadLibrary(path, lib) that uploads a .so as a blob and sets lib.library_blob_id in-place (like in the new C# SDK).

• TaskDefinition / BlobDefinition (new user-facing API): callers no longer need to pre-allocate result IDs or upload blobs manually. BlobDefinition::FromData(bytes) provides raw data to be uploaded on submission; BlobDefinition::FromBlobId(id) references an already-uploaded blob. Submit(TaskDefinition) uploads all raw inputs in batches (reusing the existing batcher and thread pool), wires them into data_dependencies so the DynamicWorker can resolve them, and then follows the existing submission path.

• IServiceInvocationHandler: HandleResponse gains a backward-compatible three-parameter overload that adds result_id (the blob ID of the completed task's result). The default implementation of the three-parameter version delegates to the existing two-parameter one, so existing handlers compile and run without changes. Override the three-parameter version to access result_id and pass it to BlobDefinition::FromBlobId to chain tasks without re-uploading.

• ArmoniK.SDK.Worker: ServiceBase gains a map-based call(session_ctx, name, inputs) overload for the convention path. The string-based call() is no longer pure virtual — its default implementation parses the convention JSON payload and delegates to the map overload, so existing legacy workers that override the string version are unaffected. Convention workers override the map overload and receive named inputs directly without any JSON parsing.

• ArmoniK.SDK.Worker.Test: new ConventionService implementing square and add by overriding the map-based call() overload, registered under the ConventionArithmetic service name.

• New dependency: JSON serialization is managed by nlohmann-json so this dependency was added to all Dockerfiles and the Debian package build-depends. For the RHEL Dockerfile the dependency is built in place. The dependency is declared PRIVATE in ArmoniK.SDK.Common and ArmoniK.SDK.Client. ArmoniK.SDK.Worker uses it for the ServiceBase default dispatch via include-path injection (not a link dependency), so it does not appear in the exported cmake targets and does not leak to downstream consumers.

• Tests: new SerializationTest.cpp with unit tests for TaskOptions convention helpers (BlobDefinition ×5, TaskDefinition ×4); added four tests to ArmoniK.SDK.Client.Test.cpp covering convention task submission, method name fallback, and task chaining. End-to-end tests in SessionHandlingTest.cpp cover Submit(TaskDefinition) for single raw input, batch submission, and no-input tasks. The chaining test (testConventionChainedSquareThenAdd) computes 2² + 3² = 13 using three tasks, feeding the result blob IDs of the first two directly into the third via BlobDefinition::FromBlobId.

Backward compatibility

The legacy execution path (application_name/application_version + binary payload) is unchanged. All existing tests continue to use it. The convention is opt-in: the DynamicWorker selects the path based on the presence of ConventionVersion in task options. The legacy path (Submit(TaskPayload)) is deprecated — TaskPayload carries [[deprecated]] and compilers will warn at call sites. HandleResponse is extended with a backward-compatible three-parameter overload; existing two-parameter implementations continue to work without modification. Use Submit(TaskDefinition) for new code.

Java sample

Check aneoconsulting/ArmoniK.Samples#172 for a Java Sample sending tasks to a Cpp worker

C# sample

Check aneoconsulting/ArmoniK.Samples#173 for a C# Sample sending tasks to a Cpp worker

[lemaitre-aneo]

The new payload definition relies on the fact that that results with the inputs are already present and known to the user, but from a user perspective, it would be much easier to have an interface where a user can just say I call this method with this raw data and let the library uploads its data for them.