Write unit (mostly) functional (some) and end-to-end (very few) tests to clearly specify the encryption future-proofing behaviour

[gkc]

Is your feature request related to a problem? Please describe.

(Part of the encryption future-proofing project)
Having done design and an implementation spike, now need to write all of the test cases which capture and verify detailed design intent

Describe the solution you'd like

A set of tests which embody the "We need to ..." parts of the following:

• We currently support one single type of public-private encryption keypair (RSA). We need to support ECC and likely others in the future
• We currently encrypt symmetric keys in one way only, by using RSA asymmetric keys. We need to explicitly store some metadata about the asymmetric key that was used to encrypt the symmetric key, and the specific encryption algorithm used (e.g. there are multiple different ECC algorithms and curves), along with the encrypted key itself
• We currently support one single type of symmetric key - AES-256. We need to support others.
• We currently support one single type of encryption - AES-256 using the CTR cipher mode. We need to support others.
• We currently support having only one public-private encryption keypair. We need to support having more than one - for migration purposes if nothing else.
• We currently support @alice having only one single shared symmetric encryption key for sharing data with @bob, and @bob likewise having only one single shared symmetric encryption key for sharing data with @alice. We need to support each atSign sharing as many symmetric encryption keys as they like with another atSign, and choosing to encrypt data with any of those shared symmetric encryption keys they wish

Describe alternatives you've considered

No response

Additional context

See #785

[gkc]

Marked urgent as it is the next task for #785 which is urgent

[gkc]

Some progress in PR51. Expect to complete this ticket and the full implementation in PR52

[gkc]

Implementation is largely complete (in theory); but little progress in PR52 on completing the automated tests to verify it all. Moving to PR53, it'll be between 5 and 8 SP effort to finish off the tests and deal with whatever bugs I find.

[gkc]

Some progress in PR53 but still incomplete due to other priorities, most notably APKAM draft detailed design

[gkc]

Complete. Tweaking implementations now to verify zero backwards compatibility impact, getting PRs ready / approved / merged