Add function to copy mutable creation items from DataBox into a TaggedTuple

[kidder]

Proposed changes

This allows data to be sent to newly created Elements from their parent or children during AMR

Upgrade instructions

Code review checklist

• The code is documented and the documentation renders correctly. Run
  make doc to generate the documentation locally into BUILD_DIR/docs/html.
  Then open index.html.
• The code follows the stylistic and code quality guidelines listed in the
  code review guide.
• The PR lists upgrade instructions and is labeled bugfix or
  new feature if appropriate.

Further comments

[nilsvu]

This technically adds a cyclic dependency between Parallel and DataStructures. Should probably be resolved by moving PUP things out of Parallel. But I have another suggestion: I have needed a get_items function in some places in the elliptic code (search for "get_items", implemented as a lambda in some places). It gets multiple items from the DataBox and returns a tuple that can be assigned to structured bindings. How about we make that a DataBox function. Then I think you can build the TaggedTuple using get_items and serialize/deserialize where you need it.

[nilsvu]

"mutable"?

[kidder]

duh 👍

[nilsvu]

drop

[kidder]

Yes, I agree we should probably make a Serialization library somewhere and put various things in it to break the dependency.
I don't think it matters whether copy_items returns a tuple or TaggedTuple, it will still need to call deserialize(serialize(item)) in order to obtain a copy of a non-copyable type.

[nilsvu]

Yes to the Serialization lib. We can place it in Utilities/Serialization/, as its own lib (because it's sort of an extension of Charm and has to live at the same low level as Utilities, below DataStructures).

I didn't suggest to switch TaggedTuple -> tuple. My suggestion is to make a get_items function with the same reference semantics as get. I think that would be very useful for things like this:

const auto& [x, y] = db::get_items<Tags::X, Tags::Y>(box);

It replaces long lists of db::get. I thought it could also be useful for copying items, but maybe it's not enough (getting item types for deserialize can be annoying).

[kidder]

Okay, so I'd prefer to refactor in a separate PR. And yes, I see the usefulness of get_items, but I need to know the storage types in order to copy the items, so again, I'd prefer adding that in a future PR.

[nilsvu]

sounds good. please squash the changes above directly.

[nilsdeppe]

LGTM, one question

[nilsdeppe]

do you only want a copy, or would a move one be useful too? If it's always a copy, that's fine, just asking :)

[kidder]

A move could also be useful and might be the right choice; I'll do that in a separate PR as moving an item will need to reset subitems and compute items that depend on the moved item...