Add selective synchronization

[fsimonis]

Main changes of this PR

This PR adds

• the dynamic attribute to provide-mesh, which allows to flag meshes as dynamic
• logic for propagating this information to other participants
• Coupling scheme self-awareness (what's my name)
• Coupling scheme synchronization (which meshes have changed locally/remotely)
• logic to determine if a coupling scheme needs to synchronize based on the above

Motivation and additional information

This handles only the synchronization. The information of which meshes change is not yet used.
This allows to further implement reinitalisation.

Closes #1293

Author's checklist

• I used the pre-commit hook to prevent dirty commits and used pre-commit run --all to format old commits.
• I added a changelog file with make changelog if there are user-observable changes since the last release.
• I added a test to cover the proposed changes in our test suite.
• For breaking changes: I documented the changes in the appropriate porting guide.
• I sticked to C++17 features.
• I sticked to CMake version 3.16.3.
• I squashed / am about to squash all commits that should be seen as one.

Reviewers' checklist

• Do you understand the code changes?

[fsimonis]

This currently doesn't work properly. Checking based on the participant name alone doesn't cover all cases. Especially if multiple coupling schemes are mixed.

I need to use the exchange tags to deduce which meshes are used in a coupling. Multi schemes need to know this for all participants.
Then I can use the global info of Participant->dynamic received/provided mesh from the participant configuration and pass it to the schemes.
Schemes can then deduce if they are required to synchronize, based on which meshes are involved in the coupling.

[fsimonis]

This works in these steps:

• <provide-mesh name="MeshA" dynamic="true"/> sets the provided mesh context to dynamic
• the participant configuration determines for all participants:
  • which receive mesh contexts are dynamic (provided is dynamic)
  • which meshes are transitively dynamic via mappings
  • which receive meshes are transitively dynamic (provided is transitively dynamic)
• in the CouplingSchemeConfiguration, exchange tags now have an extended purpose
  • if data is exchanged via a dynamic mesh (fully or transitively) in either participant, then it marks the couplingscheme to require synchronization
  • multi-coupling schemes now use synchronization if any (!) participant exchanges data via a dynamic mesh.

CouplingScheme::isSynchronizationRequired() can now be used in the SolverInterfaceImpl to deduce if the intra-synchronization as well as first and second synchronizations require extra handling.

[uekerman]

Very clean code 👌

I did not follow each and every detail, but the overall functionality looks good. It would, however, be good to have some dev docs on this overall functionality: what first and second synch is and how the transitive spread of dynamicity works. Could be a page in the dev docs to which we could link from the source code.

I think it would be good to also extend the unit test of MeshContext:

• Cases with more than 2 participants (and compositional or multi coupling schemes)
• Case with multiple mappings from or to the same mesh

Do (more) unit tests in cplscheme make sense?

[fsimonis]

I ran into trouble with Multi-Coupling cases.