seek, locate and destroy direct imports of pynacl

[DMRobertson]

For reasons, signedjson generates instances of pynacl's SigningKey and VerifyKey and then monkey patches new alg and version attributes onto them.

We (Synapse) never use pynacl directly as far as I can see. There are a number of type hint instances which refer to nacl.* when they should instead refer to signedjson.types.*.

I think we should

• replace any uses (including type hints) of stuff from pynacl with their signedjson equivalents
• no longer have synapse directly depend on pynacl.

(Ideally, signedjson would have its own types/classes etc rather than resort to monkeypatching. But one thing at a time.)

Crossref: #12324.

inspiration

[DMRobertson]

In more detail, searching the source tree for nacl yields three hits.

1. test_event_signing.py. I think we can use signedjson.decode_signing_key_base64 to create self.signing_key in the test setup method.
2. test_keyring.py. Only used for a type annotation. I think this type annotation is wrong and it should be signedjson.types.SigningKey. Likely unspotted because this file is ignored by mypy.
3. contrib/cmdclient. We generate a nacl.signing.VerifyKey but pass it to a function expecting a signedjson.types.VerifyKey. I think this is just broken; I suspect no-one has used this script in a long time. I think signedjson.decode_verify_key_bytes together with binascii.unhexlify might be enough to fix this.