Add version conflicts to entity updates

[ktuite]

Depends on #509

• Represent conflicts in the database somehow (on entities or entity_defs table?)
• Detect the conflict (base version noted in submission does not match latest version on the server)
• Save that there was a conflict
• Expose conflicts on the API

Should be able to compute

• how many entities are in conflict in a given entity list
• which entity is in conflict
• (probably) which entity def introduced the conflict

API changes should enable the following frontend PRs:
#500
#502
#503
#504

[matthew-white]

My current thinking is that we could implement this as two columns:

• entity_defs."conflictStatus". One of 'hard', 'soft', or null. This reflects whether the entity def conflicts with prior entity defs, not later ones. The value would never change.
• entities."resolvedAt". When were conflicts on the entity last marked as resolved? When counting conflicts, we would only include entity defs created after this timestamp.

[matthew-white]

API changes

Frontend needs conflict counts in multiple places. For #505 and #507, Frontend also needs the diffs of the conflicting entity versions relative to their base version ("author's view"). The current diffs endpoint compares entity versions sequentially ("Central's view"), which Frontend still needs. But Frontend now also needs a way to diff conflicting entity versions relative to their base version.

In addition, Frontend needs to know for each conflicting entity version whether it is a soft conflict or a hard conflict. In the case of a hard conflict, it needs to know which properties conflict. (I guess a soft conflict is just the case where the list of conflicting properties is empty.)

For #505, Frontend also needs to receive data about the "known good" version and all base versions.

[ktuite]

I'm copying this note from @lognaturel to here because its relevant to how we think about conflicts:

My recollection was that we weren't going to do three way merging and would instead do last-received-wins with detection of

• "simultaneous updates": the last received updating submission's base version is not identical to the server's current version and there is no overlap between the properties updated by this submission and properties changed by any updates made since the last received submission's base version
• "conflict": the last received updating submission's base version is not identical to the server's current version and there is overlap between the properties updated by this submission and properties changed by any updates made since the last received submission's base version

IIRC, we mostly reached this conclusion based on the assumption that updates from submissions would generally be diffs already. That is, if a property isn't changed by a form, it wouldn't generally be sent. That assumption would be incorrect if users decide to build forms that are more for data management than worfklow management so we would track frequency of conflicts and reconsider more sophisticated merging if they happened a lot.

There's ongoing discussion in slack but I'll summarize it all here in this issue once we get to a decision.