change pointer returned by Serialize() to be smart

[Yurlungur]

PR Summary

@adamdempsey90 pointed out that Serialize() is a bit unsafe as it returns a pointer that then must be managed by the host code. This is subtle also because, depending on how an EOS is deserialized, that pointer may need to stick around for the lifetime of the EOS.

To make things a bit safer, I make Serialize() return a smart pointer and add some additional documentation. I note that I am a little torn on this as this is the only place in the code that smart pointers are used. So I worry that it may create a pattern with an exception... i.e., you always must manage your memory except for this one case.

Nevertheless it is a bit cleaner.

PR Checklist

• Adds a test for any bugs fixed. Adds tests for new features.
• Format your changes by using the make format command after configuring with cmake.
• Document any new features, update documentation for changes made.
• Make sure the copyright notice on any files you modified is up to date.
• After creating a pull request, note it in the CHANGELOG.md file.
• LANL employees: make sure tests pass both on the github CI and on the Darwin CI

If preparing for a new release, in addition please check the following:

• Update the version in cmake.
• Move the changes in the CHANGELOG.md file under a new header for the new release, and reset the categories.
• Maintainers: ensure spackages are up to date:
  • LANL-internal team, update XCAP spackages
  • Current maintainer of upstream spackages, submit MR to spack

[adamdempsey90]

LGTM, and credit goes to @buechlerm for pointing this out to me

[buechlerm]

Just read your summary. If you don't like returning a smart pointer, should we consider eliminating a serialize that allocates memory all together and force the user to do it? I suppose that depends on whether this overload is used in the wild or not.

[Yurlungur]

Just read your summary. If you don't like returning a smart pointer, should we consider eliminating a serialize that allocates memory all together and force the user to do it? I suppose that depends on whether this overload is used in the wild or not.

I think this overload is basically only used in the tests as syntactic sugar. In the wild, pre-allocating is vastly preferred because of MPI shared memory. So I would be willing to remove it entirely. But I think it's also fine as a one-off.