Sanity checking in release builds

[eboasson]

From #125:

From personal experience, additional debugging checks are useful to include in production release, as they allow to quickly localize subtle errors such as "memory rubbing" or incorrect functioning of hardware. However, in these conditions, not global assert () was used, but return from the function with an error code and write to log error information: a unique 32-bit HEX-number (generated by a macro from the development environment), a call stack as a sequence of 32-bit numbers and additional information related to the error that occurred. This scheme has a number of advantages over assert(): strings with file names are not stored, the error is quickly found by the development environment with a single HEX-number, and even in the case of inserting new lines to source, the decision on processing is made not globally, but in each thread, depending on the severity of the failure. Although there are drawbacks such as the need to make the signature of the function additional argument for the organization of the call stack and the logger.

[i-and]

Hi @eboasson, Please specify how you see the implementation. Do you want to create a corresponding subsystem in ddsrt, for example named 'diag'? Do you plan eventually in code of CycloneDDS to abandon the use of assert() in favor of this new subsystem (considering the possible changes signatures of the functions)?