List of API-breaking improvements

[mdorier]

In this issue I want to track a number of improvements that would break Margo's API but would generally lead us towards better coding practices. We can discuss them and think of a time where we decide to implement them (maybe for a Margo 1.0 ?).

More consistent error codes

Right now most Margo functions return an hg_return_t. Some functions return an int that can be interpreted as a boolean. Some return an int that can be interpreted as an Argobots error code. Some will return -1 or HG_OTHER_ERROR for an error that is not caused by Mercury but for which we don't have an error code (e.g. a configuration error).

This is not great. I would suggest adding a margo_ret_t type, tyepedef-ed as an int, with the following semantics:

• If the margo_ret_t code is between 0 and HG_RETURN_MAX, then it is convertible and interpretable as an hg_return_t.
• If the margo_ret_t code is negative, then its opposite is interpretable as an Argobots error code.
• If the margo_ret_t is greater than HG_RETURN_MAX, then is is interpretable as a Margo-specific error code, which would be defined as a #define.

No return value other than an error code

Some functions return something else than an error code. For instance the margo_init family of functions return a margo_instance_id. This prevents us from returning a value explaining why initialization failed (did Mercury fail to initiailze? Was the JSON file incorrect? Something else) without turning on logging.

Ideally, all functions should return an error code. Functions that currently return something else should have that something else returned via a pointer to an output argument.