Previously, running /auth command would immediately send off request
with the provided username, and all keyring actions will only happen
once the client receives the challenge. This isn't possible now that we
have both software X25519 and hardware P-256 keys because we must signal
which key type we're using in advance.

Rather than deferring everything until the challenge, perform the key
setup immediately. Parse it, load it into the auth state, and send the
full request. When the challenge is received, all that's left is to
unlock the already resolved key. In case user cancels the prompt, open
key selection dialog again.

Make auth state machine stricter, so it's more consistent and easier to
reason about, and only expose small interface. In particular, it
provides key switching without restarting the auth flow. The state
itself is only initialized once at program start, fully static, and
avoids superflous allocations and deletions which could result in
invalid states. Unify auth-related structures under it that were
previously separate, such as saved hostname-username pairs. Send signals
about request and response being ready instead of directly using the
network functions, which makes it especially better fit in context of
two asynchronous dialogs.

To properly encode hardware or software key type in the intitial request
without creating a separate packet, an extension to subprotocol 2 was
introduced in a format-violating manner: an extension bit set means a
hardware key is used, and thus we'll expect an ephemeral P-256 key as
the challenge. The entire credential message format will be completely
rewritten in version 3, this is a prototype implementation.

The key creation is handed off to the platform implementation. Windows
will show its own Windows Security UI. On Unix, the application itself
provides the PIN directly, enforcing a minimum of six characters.

Hardware keys are created and managed exclusively in the protected
environment of the Trusted Platform Module (TPM 2.0), a separate, secure
processor isolated from the rest of the system. Keyring provides them as
an alternative to established software keys for challenge-response
authentication.

Software keys, while far more secure than naive passwords, have their
limitations. They're stored in a keyring file in an encrypted form and
can be extracted and copied. As a result, it's possible to perform
unlimited attempts to decrypt them offline. To mitigate such attacks, a
memory-hard key derivation function must be used to derive the
decryption key, and the passhprase itself must still be sufficiently
strong because a small search space will definitely be exhausted. A side
effect of this is a massive latency spike and potentially disruptive
peak memory usage.

Hardware keys, by design, are non-exportable. Total system compromise
won't lead to key exfiltration due to TPM having no such functionality,
and TPM's tamper resistance makes extraction of secrets infeasible even
with physical access to the machine (if the TPM is genuine).

PIN that is used to protect hardware keys is validated by the TPM
itself, which also locks itself out after too many failed attempts. This
lockout cannot be overridden without either issuing a lockout clear
command with authorization value or resetting the TPM outright, erasing
all keys stored in it. Because of this, low-entropy secrets (such as
six-digit PIN) can provide sufficient security.

Their only limitation is the flipside of their strength: because they're
non-exportable, you can't back them up and move them between devices.
Once created, a hardware key is bound to the machine, unlike software
keys which are usable everywhere as long as you have keyring.cbor.

Hardware keys require TPM 2.0 and an API to communicate with it.
Implementations are provided for:

- Windows via Cryptography API: Next Generation (CNG) with Microsoft
  Platform Crypto Provider.

- Unix systems with TPM2 Software Stack (TSS2).

Windows scopes keys to a Windows user, so you likely won't be able to
move them across users or installations within the same machine. The
keys will remain on the system with "SoF_Auth_" prefix and a UUID so you
can locate them in your key registry. They'll additionally have the name
you set at key creation.

Unix might require additoinal user permissions to access the TPM. For
example, adding a user to the `tss` group on Linux.

The platform input differs. Windows can take a user-friendly key name to
display, which is a good feature considering weird requirement of
Windows that key names (actual identifiers) must be unique strings, for
which I use UUIDs. Unix has no concept of key names or identifiers, but
it has to provide PIN to the TPM directly.

Windows uses its own PIN prompt from Windows Security UI that's
disconnected from the application. This is somewhat awkward because it's
modeless. Also, a ridiciulous quirk of Windows CNG API makes it so key
handle creation returns the same `NTE_INVALID_HANDLE` error no matter
what kind of error it was. In particular, it's impossible to
differentiate between the operation failing due to the TPM lockout, or
the user voluntarily closing the dialog. The user will always see
"hardware locked out" error message. Brilliant API design.

The PIN is implemented as a direct authorization value for keys, so it
might be vulnerable to the bus sniffing attack if the PIN is traveling
in clear between CPU and TPM. Though, a hypothetical adversary who's
sitting with a logic analyzer hooked up to your motherboard as you type
the PIN will realistically have easier means to log your keystrokes.

TPM is capable of remote attestation to prove its authenticity, but I
chose to avoid it to protect users' privacy (there's anonymous
attestation, but it's not always practical because it requires special
CAs) and avoid significant implementation complexity on the server that
the attestation entails, such as parsing and validating certificate
chains.

Because of the unfortunate reality, TPMs overwhelmingly have no support
for X25519 (the key exchange algorithm used in software keys). It was
added in a recent revision, but it's yet to be implemented, and only on
the newest machines. You can't upgrade the TPM hardware, so we have to
compromise. Instead, elliptic curve Diffie-Hellman over P-256 curve has
been selected, which is also the default curve used in WebAuthn
(passkey) protocol. It's ubiquitous, supported by every single TPM 2.0,
and secure if reasonably implemented.

Keys don't take up limited nonvolatile memory of the TPM. Every
reference to TPM objects necessary to perform authentication is stored
on disk, and keys and contexts are recreated on every operation and
cleared from memory afterwards.

For the client public key format, I *only* use compressed P-256 points
(1-byte parity of y coordinate followed by a full 32-byte x coordinate)
for robustness. Their designated identification byte is 0x33, and they
start with the letter M when base64url-encoded.

Change Argon2id parameters from 1 gigabyte of memory and 3 iterations
to 2 gigabytes and 2 iterations. Memory cost is the primary parameter
that provides substantial hardening, and 2 GiB in particular is
recommended by RFC 9106 (here with an additional iteration). This will
impact performance of key derivation on devices with constrained RAM,
but platform-backed keys should provide an alternative.

Enforce minimum of 6 characters for the passphrase. This is still not
enough considering an adversary can make unlimited offline guesses,
even with significant slowdown. However, this is consistent with
modern practices for authenticator policies (recommended, for example,
by NIST SP 800-63B-4): enforce minimal length and nothing else.

Remove -pipe because this option is dubious and doesn't do anything.

Get rid of unwind tables. They instrument call sites (synchronous) and
any instruction boundary (asynchronous). In the release build, they only
inflate the size of the executable. Synchronous tables are necessary
for C++ exceptions, but, thankfully (and I can't praise the developers
enough) AO2 Client doesn't use them at all.

Add RELRO and NOW to the linker. While I've already removed PLT at code
generation phase with -fno-plt, turns out, ld still stupidly performs
lazy linking: the symbols are moved to GOT, but not immediately
resolved. That was an oversight of mine, so bring back full RELRO.

Add packing of relative relocations. These are moved to a separate
compact section, where they're encoded more efficiently.

- Downstream version and the upstream revision it's based on
  (commit and date)

- URL to our modified source code.

- miniaudio and libsodium versions.

- Build profile (release, dev, or debug).

Also, stop checking for updates.

We only support Qt 6, remove all conditional code that was dependent on
earlier versions.

Let users explicitly enable logging if they so desire. Don't clutter the
disk space and perform I/O for each line when the rest are unaware.