[WIP] Fix change on disk detection

[koppor]

This will solve the whole change-on-disk-dection things similar as conflicts are solved for a shared-database. This PR builds on #5640 and is an alternative to #5665.

Implementation motivation

In 2016, I designed the database synchronization feature (https://docs.jabref.org/collaborative-work/sqldatabase), which I briefly described at #2866 (comment):

• Multiple users should be supported "seamlessly"
• If user A and B work on the bibfile, a modification by user A on a bibtex entry B1 should not trigger any "changes" dialog if user B did not do any changes.
• A "Merge Entries" dialog should popup if users A and B modified the same entry.

How this works can be tried out using the Shared SQL Database Feature of JabRef, where @obraliar and me worked hard to have a very nice user experience.

Technically, this is not that easy to achieve. However, users will be happy, if it "just works".

At each instance of JabRef:

• Local state L is known
• Remote state R is known
• In case an update is made remotely, the diff can be applied to R.
  So R' is known. Based on R and R', the entries E where a change was made, are known.
  Based on E, changes can be applied to L.
  If in L the entry was not modified: just apply the update.
  If in L the entry was modified: Start the merge entries dialog.

Implementation idea

Current implementation state

TODO:

• Add tests (multi-threading: update file in parallel, ... !)
• saved flag local in the update monitor
• Work on work on BibdatabaseDiff only
• Trigger the merge entries popup

Optional:

• Instead of the merge entries dialog, the changes should be displayed
• Add a button to the change display panel to open the merge entries dialog, because the merge entries dialog has a visual diff instead of a text-only description.

DONE:

• After a synchronization is triggered: the referenceFile is updated with the current database
• Synchronize change detection and file writing: should not happen in parallel
• Use !Thread.currentThread().isInterrupted() instead of true in endless loop in thread

• Change in CHANGELOG.md described (if applicable)
• Tests created for changes (if applicable)
• Manually tested changed features in running JabRef (always required)
• Screenshots added in PR description (for bigger UI changes)
• Checked documentation: Is the information available and up to date? If not: Issue created at https://github.com/JabRef/user-documentation/issues.

[Siedlerchr]

Use Thread.onSpinWait in addition to give an optimization hint for the cpu
https://jaxenter.de/java-9-jep-285-spin-wait-loops-65884

[tobiasdiez]

The biggest problem I see is to have a robust 3-way merge, that takes all the changes, applies some automatically and only reports conflicts. The problem is that the bibtexkey can change, so that you don't have a definitive way of telling which entries in the 3 databases correspond to each other (e.g. the user renames a key, and creates a new entry with the old key). For shared libraries, you solved this by introducing a unique identifier for each entry...

Please don't forget that there are more than entries that can change (groups, strings, meta data, ...).

So how should we proceed? I agree that this PR is a better alternative to #5665 but there is still a lot of work required to make it work. Should we for now merge #5665 for now and then revert it after the 5.0 release?

[koppor]

To prevent issues such as #4877 i added synchronized at some places. Maybe, this could be a quick fix to solve that issue?

Maybe, having a working with maximum job count of 1 for saving could help. Refs #5680 (review)

[koppor]

Will take longer to work on this. Therefore moved to koppor#442.