Refactor staging functions

[jenest]

Description

Refactors common code in staging functions of unifyfs-rm.c into a generic_stage() function.

Motivation and Context

Addresses issue #516.

How Has This Been Tested?

Using tests 0700 and 9300 on Summit. Unfortunately, these tests fail for either dev or my own branch. However, @CamStan is not seeing these problems on LLNL systems.

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.

[CamStan]

Not sure it has anything to do with this, but I recalled that there is one stage test currently set as test_might_fail, but I don't recall why this decision was made. Might have been a failure that only showed up on Travis and not locally and never got debugged on Travis.

UnifyFS/t/0700-unifyfs-stage-full.t

Lines 60 to 62 in b5d723d

	test_expect_success "final output is identical to initial input" '
	test_might_fail test_cmp ${UNIFYFS_TEST_TMPDIR}/stage_source/source_0700.file ${UNIFYFS_TEST_TMPDIR}/stage_destination_0700/destination_0700.file
	'

Essentially, even if this test fails on Travis, it will show as passing, which is something we should probably adjust in the long run.

[jenest]

I would probably agree that this should be adjusted, but I might let someone that has more experience with this code make the call for whether/how that should be done.

[jenest]

It might be best to make sure things are working so I can test my changes. Currently, tests 700 and 9300 are failing on Summit, even with the dev branch.

@MichaelBrim Thoughts on addressing this?

[MichaelBrim]

@jenest I would just open another issue to resolve problems that already exist.

[jenest]

Referenced in a comment on issue #523. I will be happy to create a separate issue if needed.

[MichaelBrim]

Now that we are generating a single c-string representation of the full launch command, it's no longer necessary to keep a separate c-string for n_nodes. Could you update the command snprintf() to just use the %zu format and pass it resource->n_nodes as an arg? This change would go in each of the xxxrun_stage() functions.