Amend the optional suggestion for clients to implement one-time key signing with suggestion to also implement plausibly deniable authenticated key exchange

**The current problem**:
If Thomas wants to send an encrypted message to Alice, he first has to
send an encrypted Megolm session to Alice. In order to encrypt the session,
he has to be able to generate a key from the shared key, which does contain his signature. Bob sends the encrypted session to his home server.

Tom’s home server then signs the encrypted session with its Ed25519
key _BHS_ . After appending the signature, Tom’s home server sends it to
Alice’s home server. Alice can now prove that she received a signed encrypted Megolm session from Tom’s home server.

She can also prove, that the encrypted Megolm session is constructed with a key from Tom’s
signed one-time key. But without the signed one-time key, Tom could still potentially deny the transcript because Tom could say that it was another client or device connected to his server that he did not
know of.

**Suggested solution**
An option could be, to suggest for clients that choose not to generate the one-time keys to also implement “`Deniable authenticated key exchange with Zero-knowledge” (DAKEZ)`, along with the Triple-Diffie-Hellman they do implement now to establish shared secret keys.

**Ref:** More on this [here](https://www.cs.ru.nl/bachelors-theses/2020/Floris_Hendriks___4749294___Analysis_of_key_management_in_Matrix.pdf), in chapter 6.

**Implementation help:** Perhaps [this](https://github.com/rtmigo/dmk_py) could help to inspire the implementation of plausible deniability in the Synapse server.

Start by reading the specification’s optional one-time-key guidance, then review the linked DAKEZ thesis and dmk_py project. No repository file, test, or entry point is named. Done would require a settled specification change describing whether and how clients should be advised to implement plausibly deniable authenticated key exchange.

Written by the indexing model from the issue text.