Investigate if we should have QtKeychain as a git submodule

[guruz]

This allows way easier compilation for potential contributors.

Questions to solve:

• Packaging? My personal suggestion is that we compile it as owncloudqtkeychain.dylib and don't use any upstream package.

[dragotin]

hmm, I am against that, for the usual reasons.

• forks are bad.
• we should support upstream as good as we can, even if it feels like we are upstream.
• qtkeychain is a useful component for us and others. Only if it has a certain level of independence it will evolve and picked up by other projects
• we're in the dirt anyway with our wired date based version numbers, and on the way out with the 0.3.0 release frank did. So the biggest pain is behind us.

After all we want to be good open source citizens :-)

[guruz]

Reopening as per discussion @jnweiger @michaelstingl @SamuAlfageme @ogoffart

Related #2558

[jnweiger]

Current status: We don't use any distro-packages of qtkeychain.
We always provide our own, as we want to have the same version (currently 0.7.0) across all platforms.

[jturcotte]

For the record, we can have the submodule without a fork.

We can point the submodule to https://github.com/frankosterfeld/qtkeychain.git, pin the SHA1 of the version that we need and do a pull request upstream if we ever need to change anything.

[guruz]

I removed this from the milestone as @jnweiger @dschmidt anyway did the linux 5.6.2 without this change.

I still think it would be good to do this to have it easier for developers to set up a build environment

[ogoffart]

Note that we could also use CMake's ExternalProject feature which is capabable fetch git repositories.

[fmoc]

We use craft to manage almost all the dependencies including QtKeychain. Only for the Linux repos, we still have system packaging on OBS, but the long-term goal is to deploy AppImages only to Linux (or alternatively system packages based on the AppDirs contained in the AppImages, thus using craft for those as well).