Compile and link agains the OpenSSL detectected by the configure script

[rgmiller]

Ensure all parts of UnifyFS build and link against the version of libcrypto set by the configure script.

Description

This change adds the variables set by the configure script (OPENSSL_CFLAGS and OPENSSL_LIBS) to the UNIFYFS_COMMON_BASE_FLAGS and UNIFYFS_COMMON_BASE_LIBS variables to Makefile.mk.

Motivation and Context

Without this change, it's possible that not all components of UnifyFS will be linked against the same libcrypto.so library. (Full details in the description for issue 792.)

How Has This Been Tested?

Built UnifyFS both with and without the change. Without the change, unifyfsd and unifyfs-stage depended on different instances of libcrypto. With the change, everything used the same libcrypto.

Types of changes

• [x] 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:

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

[rgmiller]

Note: We aren't setting --rpathwhen we link against libcrypto. Furthermore, spack no longer modifies LD_LIBRARY_PATH as part of its module loading process. This results in an odd edge-case: If the user is using a spack environment, then UnifyFS will compile and link against the spack-built version of libcrypto, but at runtime might still dynamically load the system-provided version of libcrypto. (The version number of the libcrypto libraries would have to match, but that doesn't mean the libraries are exactly the same.)

Do we want to do anything about this? And if so, should it be part of this PR or a new one?

[adammoody]

Thanks, @rgmiller !