Add demo kdbx file (password is secret)

[wolframroesler]

The demo.kdbx password safe contains a number of realistically looking
but imaginary accounts for popular web services (Amazon, eBay, Google,
etc.) The owner's name is supposed to be John Doe, his e-mail address
is john.doe@example.com.

The intended use of this file is:

• To try out features (like the upcoming Paper Backup, Paper Backup (aka printer/PDF output) #3277) without
  using one's own database.
• To have a more-or-less realistic database file. The other kdbx files
  in the tests/data directory all have some peculiarity or another.
• To have a password database from which one can take screenshots in
  order to demonstrate bugs or new features. So, the recommendation
  "don't include screen shots of your database" can be changed to
  "include screen shots of the demo database".
• To have something you can mess around with without being afraid to
  mess up your own database. If you mess up too bad, use git to revert
  your changes.

The location of the demo database is tests/data/demo.kdbx. The
password is secret.

So far, the demo database is in the source tree only, to be used
by developers. Someone else may decide whether it could be placed in the
distribution, or maybe even made available for download from the KeePassXC
web site so that new users have something to play around with.

Type of change

• ✅ New feature (non-breaking change which adds functionality)

Description and Context

See above. Added two files, demo.kdbx with the demo database and demo.key
with the password.

Screenshots

Testing strategy

New database tested manually. No existing components were changed.

Checklist:

• ✅ I have read the CONTRIBUTING document. [REQUIRED]
• ✅ My code follows the code style of this project. [REQUIRED]
• ✅ All new and existing tests passed. [REQUIRED]
• ✅ I have compiled and verified my code with -DWITH_ASAN=ON. [REQUIRED]

[ba32107]

I really like this idea! Although I think its real benefit would only shine if all (most) fields would be filled out. It would be really useful to have a test DB that contain realistic data that would show how people really use the specific fields and features.

For example, just off the top of my head:

• Notes, expiry, URL fields
• Attributes
• Attachments
• Subgroups on multiple level, entries within those groups
• TOTP

[droidmonkey]

This will be good to have a consistent DB to use for screenshots in documentation as well. Can you move it outside the tests/data folder and put it in the share folder?

Some more things to add:

• sub groups
• KeeShare share (perhaps make a "demo_shared.kdbx")

[wolframroesler]

@ba32107 Good point. Added some more sophistication to the demo database. The idea is to be realistic without exploring edge cases, demonstrate without showing off. Show the average case, not the extremes. Be intuitively understandable without much need for explanation. Feedback is welcome, of course, everybody has their own idea of what "realistic" means.

[fdisp]

providing a “demo” password database with a publicly known password to non technical users will lead them to use that database for their own accounts and expose them.

[droidmonkey]

LOL I doubt it

[droidmonkey]

I would like to deploy this into the share directory of our release. I foresee this as the future way to implement a form of a tutorial or sandbox that is easily accessed. In the share director the database would open "read-only" and we could explicitly require changing the password if the user did a save-as operation.

[wolframroesler]

Glad you like it. :) Anything else I can do before it gets merged?

[wolframroesler]

Still need to describe the demo database in the change log file. In the distribution, in what location will demo.kdbx be installed on the client machines? Would like to mention that in the change log entry.

[droidmonkey]

Don't worry about the changelog I do that up just before release. This PR does not move the database anywhere, as far as I can recall.