new config setting - margo.server_address

[MichaelBrim]

Description

Allows users to explicitly set the Mercury address to use for server-to-server communication.

Motivation and Context

Useful when there are multiple interfaces that support the ofi+tcp protocol, or to use a different protocol.

How Has This Been Tested?

Tested in a docker environment using different network interface and protocol.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Performance enhancement (non-breaking change which improves efficiency)
• Code cleanup (non-breaking change which makes code smaller or more readable)
• Breaking change (fix or feature that would cause existing functionality to change)
• Testing (addition of new tests or update to current tests)
• Documentation (a change to man pages or other documentation)

Checklist:

• My code follows the UnifyFS code style requirements.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• All new and existing tests passed.
• All commit messages are properly formatted.

[MichaelBrim]

@CamStan Have you had a chance to figure out why the CI builds are not running?

[CamStan]

Have you had a chance to figure out why the CI builds are not running?

@MichaelBrim My apologies for the delay on this. I have the builds mostly working again, but am hitting a compilation error that I've argued myself in a circle on what a fix for this one might be:

testutil.c:20:12: error: static declaration of ‘asprintf’ follows non-static declaration
   20 | static int asprintf(char** strp, const char* fmt, ...)
      |            ^~~~~~~~
In file included from testutil.h:28,
                 from testutil.c:17:
/usr/include/stdio.h:403:12: note: previous declaration of ‘asprintf’ with type ‘int(char ** restrict,  const char * restrict, ...)’
  403 | extern int asprintf (char **__restrict __ptr,
      |            ^~~~~~~~

Builds are here: https://github.com/CamStan/UnifyFS/actions/runs/17686445589

[MichaelBrim]

@CamStan Yes, same issue as reported in #822 . I have a commit in my service-pool branch with my suggested fix, which is to not override the system definition and just use our own custom function (see #822 (comment))