Information on buffer size used after serialization

[mdorier]

Is your feature request related to a problem? Please describe.

For monitoring purpose, I would like to know RPC input and output sizes after serialization. The use-case would be to capture the patterns of arbitrarily complex Mercury/Margo-based applications and do a trace replayer that replaces the potentially complex datatypes used by the application with "dummy" datatypes that take up the same space when serialized. For this to be possible, we need to be able to monitor how much buffer space was used when the original application's datatypes were serialized by Mercury.

Describe the solution you'd like

On sender:

size_t size;
HG_Get_serialized_input_size(handle, &size); # size will be 0 because HG_Forward hasn't been called yet
HG_Get_serialized_output_size(handle, &size); # size will be 0 because the RPC hasn't completed

HG_Forward(handle, ...);

HG_Get_serialized_input_size(handle, &size); # size will be the size copied into an internal Mercury buffer when the input was serialized by HG_Forward
HG_Get_serialized_output_size(handle, &size); # size will be 0 because the RPC hasn't completed

// after the RPC has completed:
HG_Get_serialized_output_size(handle, &size); # size will be the size of the buffer internally used by Mercury to hold the serialized output

Similarly on receiver, HG_Get_serialized_input would have a value right away (because the RPC was received and should have its data in a buffer already), HG_Get_serialized_output would have a relevant value only after HG_Respond is called.

Describe alternatives you've considered

Alternatives would include being able to inject a callback into the serialization path so that this callback can see all the serialized data passing (e.g. a function that by default is a memcpy but could be overwritten by something else). Note that this solution would also allow to do cool things like transparent compression/decompression that is agnostic to the user-provided data types.

[soumagne]

Closing as duplicate of #751