VPN-6300: Refactor CryptoSettings and implement for Flatpaks

[oskirby]

Description

CryptoSettings were never really a class and just a namespace of static methods, which made it challenging to implement for flatpaks because we need to interact with an XDG portal to fetch secrets and we need some interaction with extra state and signals.

Further complicating matters for Flatpaks, the Secrets portal states that we may be given a token string back by the platform and we need to store it somewhere for the next time we fetch secrets. This presents a chicken-and-egg problem in that we can't store it in the settings if they're encrypted. To address this, we add a new EncryptionChachaPolyV2 file format, which adds a metadata field to the file header where plaintext values can be stored. These values are then passed back to CryptoSettings::getKey() during key lookup.

This is a PR that has been kicking around in my local branch for a while and I figured it was time to get it moving again. In this work we:

1. Refactor CryptoSettings into a virtual class which can be instantiated by a platform implementation.
2. Refactor some common XDG portal helpers into an XdgPortal class.
3. Refactor CryptoSettings::getKey() to return a QByteArray. Not really necessary but it just makes it more Qt-ish.
4. Implement an XdgCryptoSettings that connects to to the XDG org.freedesktop.portal.Secret portal.
5. Provide a mock CryptoSettings implementation for testing.
6. Extend the CryptoSettings to provide additional metadata for key lookup.
7. Add a new EncryptionChachaPolyV2 file format to embed plaintext metadata.
8. Write unit tests for CryptoSettings

This turned into a pretty gnarly PR, but it seemed like the best way to do it. Some other solutions considered to the token storage problem:

• Ignore it altogether: From my testing on Gnome and KDE it seems that neither of these two platforms make use of the token and if we just omit it then the secrets portal works fine. We don't really have a viable solution for key rotation via CryptoSettings::resetKey() though but I guess we could do some shenanigans with inserting a salt into the unused bytes of the nonce or something.
• Add a second (plaintext) settings file just to store the salt and token. This also works, and it was even what I was using earlier in this PR. But then it becomes another artifact to manage (and delete) and what happens if it gets out of sync with the settings file?

Reference

JIRA issue: VPN-6300

Checklist

• My code follows the style guidelines for this project
• I have not added any packages that contain high risk or unknown licenses (GPL, LGPL, MPL, etc. consult with DevOps if in question)
• I have performed a self review of my own code
• I have commented my code PARTICULARLY in hard to understand areas
• I have added thorough tests where needed

[mcleinman]

Approval for iOS/macOS - that part looks good. Thanks.

The crypto stuff generally looks great, but would either want someone closer to crypto to review it, or for me to take a lot longer to go over it with a fine toothed comb.

[strseb]

r+wc

I still need to debug why the unit test is segfaulting on my macos machine only :/
(Client works fine tho)

[strseb]

That is not needed , as the constructor does that, no?

[strseb]

Thank you so much for adding tests! :)