Versioning of all IPC capable elkodon_cal constructs

[elfenpiff]

Problem

When two elkodon_cal constructs interact with each other, we need to add some initial versioning information to ensure that not to incompatible versions of the same constructs are interacting. This could lead to undefined behavior and hard to unravel bugs.

They could be, for instance incompatible since the member order of shared management constructs has changed or members have been added/removed. Or the internal communication protocol was updated.

Solution

Introduce a const SHM_API_VERSION: u64 constant inside elkodon_cal, that must be checked before any of these constructs start to interact on an ipc level.
Constructs that use shared memory could add this constant to the beginning, as the first value, to their shared memory. If the construct does not use shared memory, one could create a file and store the number value is binary, or human-readable value, in there.

[elfenpiff]

@elBoberido Oh I think this is an important one and needs to be addressed quickly. This morning I remembered that you told me once that you add this feature always right from the beginning when you write serialization code.

[elBoberido]

If you mean something like having a SHM_API_VERSION in each shared memory file, then yes. If you want to add it to each struct, e.g. a vector then maybe not 😅

Oh did you version the config file?