Diffing the data model after saving on the backend

[olemartinorg]

Description

Currently we send the data model to the backend, which saves it to storage, and sometimes makes changes to it in the process. The backend then diffs the changes using JsonHelper in order to produce a changedFields the app-frontend can use to populate these changes back into the data model.

We should instead swap the responsibility so that the backend instead sends us the entire data model (as it looks after their changes to it), we can produce a diff from what we sent the backend and what we got back, and inject those changes into the current data model (in a way that won't overwrite any changes we've currently made to the data model while the saving request was processing).

This has a few advantages over the current method:

• The backend doesn't need to know details about the way we store the data model client-side (i.e. dot-notation paths).
• Logic needed on the backend is reduced, so it may be easier to implement a backend in other languages than C#
• Casts/changes/omissions on the backend due to a strictly typed data model is easier to catch by the user/app developer. If the data model on the backend removes data not found in the model implicitly, this is not communicated back to the frontend yet - causing problems like Specifying an invalid dataModelBinding in layout silently fails #743.
• Problems like the infamous 'saving a numeric field with a larger number than is allowed on the backend' may be easier to work around - assuming the backend will be able to cap an input to its min/max limit and return the new model back to us.

Something like this obviously needs to be coordinated with the backend libraries in app-lib-dotnet.

Additional Information

• Backend issue: Return the full data model to app-frontend after processing a write operation app-lib-dotnet#316
• Idea origin: Refactor and write tests for JsonHelper in DataController app-lib-dotnet#116 (comment)
• Require a minimum backend version in v4 #1496

[olemartinorg]

Most of the functionality here is already implemented in #1175 (PR #1712), and the rest will be in #1714.