GitLab

This PR brings the following important changes to margo:

• The code has been modularized to avoid putting everything in margo.c. The modularization is not perfect but it's a start.
• As a consequence, many of the functions that used to be static in margo.c are now global. To recognize that they are internal to Margo, they have the __margo_ prefix.
• Static variables that are now global have the g_margo_ prefix.
• The PR completely refactors the way margo is initialized. margo-init.c contains the margo_init_ext function that initializes margo by considering all possible cases of user-provided and JSON-based options.
• Move away from Jansson and use JSON-c instead (also remove dependency to mochi-cfg).

This is a WIP. Remaining are the following to do:

• Adding an API to access internal pools and ES created by margo from the "argobots" section of the configuration.
• More testing. I plan to add munit unit-tests to start having more tests. I'll start this test framework with tests on the new init function.

Explanation on how margo_init_ext(const char* addr_str, int mode, const struct margo_init_info* extra) works: The margo_init_info structure allows the caller to specify externally-initialized structures, such as the hg_context, hg_class, progress_pool, rpc_pool, etc. as well as a string representation of a JSON config. The function starts by looking at what is provided in the margo_init_info passed by the user and builds a standard JSON configuration from it (e.g. filling out all the missing information from a potentially user-provided JSON). The idea is that by getting this completed and validated JSON state, one can restart margo exactly in the same way, down to how each ES was pinned to particular cores, and each option of Mercury. An example of JSON configuration is shown at the beginning of margo.h.

Note that the JSON configuration allows the caller to specify any set of pools they may want to see margo create for them, and any set of ES attached to these pools. The progress pool and RPC pool are just two special cases now, but the user can ask for more pools to be created. This opens the possibility to easily have margo create the pools/ES setup, and then bind provider to specific pools.

Note also that in the JSON, pools and ES can be identified by a name. margo_init_ext validates that the names match existing pools/ES in the configuration, and they are unique. It then replaces names with indexes (so if you pass the example JSON to margo, then call margo_get_config(), what you will get back will have numbers instead of names).