[Tracker] Future-proof our encryption and encryption key management

[gkc]

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

• 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, 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 the solution you'd like

• 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

### High-level tasks (please add additional tasks here!)
- [x] [Draft, review and agree a high-level design](https://github.com/atsign-foundation/at_client_sdk/issues/786)
  - [ ] Annouce at IoT World Solutions Congress Barcelona Jan 31- Feb 1 (?)
- [ ] High-level marketing / launch plan (how do we talk about this, why it's important, why it's cool, how to use it, etc)
- [x] [Spike the overall implementation](https://github.com/atsign-foundation/at_client_sdk/issues/787)
- [x] [Specify and verify the intended behaviour in detail, by writing unit, functional and end-to-end tests for all of the "We need to ..." above](https://github.com/atsign-foundation/at_client_sdk/issues/821)
- [ ] [Full implementation](https://github.com/atsign-foundation/at_server/issues/1271)
- [ ] "How to" guides on docs.atsign.com
- [ ] Text or video (or both) content for posting on social or our website

[gkc]

High-level design drafted and reviewed during PR49