Fix issues with reloading and handling of externally modified db file

[vuurvli3g]

Based on the discussion of issue #5290 and analyses, I've come to the following list of issues.

• Reloading is one-shot. If it is not completed successfully there is no mechanism to retry:
  Some scenarios where a reload will not complete successfully.
  • If the user is busy editing a group/entry the reload is ignored.
  • The user has auto-reload disabled and chooses "No" upon being asked to load the external changes.
  • The db file could not be opened with the same key used to open the db:
    • The YubiKey is not inserted
    • A different YubiKey is inserted (programmed with the same secret)
    • The window for touching the YubiKey was missed
    • The keys of the db file have changed (password changed, YubiKey added/removed, ...)
• Overwriting a db file that was modified externally should not be possible (unless explicitly requested):
  There is code in place that is supposed to protect against this but it doesn't function as intended.
  

  keepassxc/src/core/Database.cpp

  Line 266 in 6f11422

  if (!m_fileWatcher->hasSameFileChecksum()) {

  
  

  keepassxc/src/core/FileWatcher.cpp

  Line 107 in 6f11422

  return calculateChecksum() == m_fileChecksum;

  
  

  keepassxc/src/core/FileWatcher.cpp

  Lines 119 to 125 in 6f11422

  	AsyncTask::runThenCallback([=] { return calculateChecksum(); },
  	this,
  	[=](QByteArray checksum) {
  	if (checksum != m_fileChecksum) {
  	m_fileChecksum = checksum;
  	m_fileChangeDelayTimer.start(0);
  	}

  
  The current hash of the file is directly saved in m_fileChecksum upon detecting the change.
  The fail-safe check therefore only works as intended in the short window that the file was modified on disk but was not picked up by FileWatcher yet.
• There is no way to provide other keys for reloading a db file:
  When keys of the db file have changed (password changed, YubiKey added/removed, ...). there should be a way to enter them.

This PR aims to address these issues.

Changes

• Cannot overwrite an externally modified db file unless requested.
• Trying to save (overwrite) an externally modified db file will trigger a reload, serving as retry mechanism.
  In the case where the user has auto-reload disabled they will not see the "File changed - Want to reload?" dialog but can make a choice at the "Reload database" dialog (see screenshot).
• An additional choice is added to the previously known "Merge Request" dialog, now "Reload database" dialog (see screenshot), to allow the user to ignore the changes in the file on disk (and overwrite the file).
• If during the reload the db could not be opened with the original key (due to missing YubiKey etc..) the user is presented with the "Unlock Database" dialog (see screenshot).

Fixes #5290

Screenshots

Testing strategy

Added test-case to TestDatabase.
Manual testing.

Type of change

• ✅ Bug fix (non-breaking change that fixes an issue)
• ✅ New feature (change that adds functionality)

[droidmonkey]

Oh this is exciting. Something I have been pondering for years how to fix properly. I haven't dived into your changes yet.

[droidmonkey]

I have wanted to introduce a new class called DatabaseFileManager or similar that would take all the file handling functions (Open, Save, Reload, etc) away from Database and DatabaseWidget. This is important because Database should just be the in-memory representation of the database and be the sole owner of the RootGroup and all it's children. Ripping out the file management code would make this relationship much cleaner. We also want to avoid the current code that splits file handling functions between the presentation layer (DatabaseWidget) and the data layer (Database).

[vuurvli3g]

I can see how it would be cleaner to decouple those things.
Is there something in relation to this PR you would like me to do?

From my limited testing it has been working OK. Would be helpful if some users that run into this issue could help test and provide feedback.
The main that has come forward for myself was that It might be nicer to use a different color for the "Reloading database..." message widget. When there is a YubiKey involved the amount of blue bars on the UI can be a bit much.
Perhaps making it the warning color (yellow) would make for a better visual experience.

I haven't planned any further changes so, I will mark this PR ready for review.

[droidmonkey]

I think we leave this PR as-is and plan for a future change, we can work together on it. Big things I really really want to refactor towards:

1. The aforementioned DatabaseFileManager
2. Transactional changes to entries, groups, and database
3. Implement Undo/Redo and Change Tracking
4. Move away from "resolveMultiplePlaceholders" garbage and introduce smart caching of "display data" outside of "stored data"

For 2, this would mean you would build a "ChangeRequest" or similar that would then be passed to the Database object to enact that change. This solves a whole slew of problems with random parts of the code making deep changes to data structures in inconsistent ways. This also means we need to shift to const objects (groups and entries) everywhere except within the owning database object.