GROMACS

Make dd_collect_vec independent of t_state

This removes the explicit dependency of dd_collect_vec on the
t_state object.

This is a prerequisite for !440.

Refs #3422 #3419

Introduce CheckpointData

CheckpointData exposes methods to read and write scalar values,
ArrayRefs, and tensors. It also allows to create a "sub-object" of
type CheckpointData which allows to have more complex members
implement their own checkpointing routines. All methods are templated
on the chosen operation, CheckpointDataOperation::Read or
CheckpointDataOperation::Write, allowing clients to use the same code
to read and write to checkpoint. Type traits and constness are used to
catch as many errors as possible at compile time. CheckpointData uses
a KV-tree to store the data internally. This is however never exposed
to the client. Having this abstraction layer gives freedom to change
the internal implementation in the future.

All CheckpointData objects are owned by a ReadCheckpointDataHolder or
WriteCheckpointDataHolder. These holder classes own the internal
KV-tree, and offer deserialize(ISerializer*) and
serialize(ISerializer*) functions, respectively, which allow to read
from / write to file. This separation clearly defines ownership and
separates the interface aimed at file IO from the interface aimed at
objects reading/writing checkpoints.

Refs #3517
Refs #3422
Refs #3419

Prepare legacy checkpoint for modular simulator checkpointing

• Extend legacy checkpointing functionality to accept a CheckpointDataHolder
  for reading and writing
• Bump checkpoint version to reflect above change
• Turn off some checkpoint sanity checks when using modular simulator
• Pass CheckpointDataHolder object into checkpoint reading in runner, and
  move this object in SimulatorBuilder and then ModularSimulator for element
  setup

Refs #3517
Refs #3422
Refs #3419

Make EnergyOutput::addDataAtEnergyStep independent of t_state

EnergyOutput::addDataAtEnergyStep took a pointer to a full t_state,
although it only uses a small part of the object. This makes the
dependencies explicit. This is a necessary step to make EnergyData
independent of t_state.

Refs #3419

Remove dependency of EnergyData on t_state

EnergyData used a t_state object to calculate the conserved energy.
This responsibility is now given to the respective temperature /
pressure control algorithms. This allows to remove the dependency
of EnergyData on t_state.

This also introduces the conserved energy as a test quantity in the
tests comparing legacy and modular simulator code paths.

Refs #3419

Make legacy energy elements use CheckpointData

This enables some legacy energy elements to write to CheckpointData,
namely

• energyhistory_t
• delta_h_history_t
• ekinstate_t

Refs #3517
Refs #3422
Refs #3419

Implement modular checkpointing

Using the CheckpointData format introduced in a parent commit, this
rewrites checkpointing for the modular simulator to completely use
the new format.

The CheckpointHelper is now passing a CheckpointData object to its
clients (instead of a legacy t_state object). Clients are now stored
in a map, as they are identified by their unique key to be able to
assign the correct CheckpointData sub-objects at reading and writing.

If checkpoint reading occured, the newly introduced
CheckpointHelperBuilder receives the CheckpointData object read at the
runner level from the ModularSimulator. It then initializes its clients
with their respective, read-only CheckpointData subobjects.

The ICheckpointHelperClient interface is adapted to reflect above
changes.

The ModularSimulatorAlgorithmBuilder is slightly simplified thanks to
to the introduction of a proper builder for the CheckpointHelper.

The ComputeGlobalsElement is simplified, as it is not required to know
about the needs of communication of the EnergyData object which
depends on checkpoint reading.

Finally, all elements which are checkpoint clients are updated to
implement the new design. Note that they all introduce their own
checkpoint versioning, as the data being checkpointed is opaque to the
checkpointing infrastructure.

Closes #3517
Closes #3422
In partial fulfillment of #3419