Design Doc: Flexibility in choosing a cryptography provider

[Shaptic]

Parent Epic: stellar/js-stellar-sdk#848

This issue is scoped to the item about sodium-native et al. being a problematic dependency.

Design Idea: Crypto provider flexibility

What if we made an assumption about the existence of a shim layer that was then provided to us as a polyfill? For example, we would write,

// in e.g. src/keypair.js
import { CryptoProvider } from 'stellar-crypto';

// the following can be assumed to exist:
CryptoProvider.sign
CryptoProvider.verify
CryptoProvider.generate

Then, the user can either leverage existing providers (sodium-native, tweetnacl, etc.) or implement their own shim layer:

mkdir -p ~/projects/stellar-crypto-shim
cd ~/projects/stellar-crypto-shim
npm -y init
touch index.js
yarn link 'stellar-crypto'

// index.js
import { createSecretKey } from 'crypto'; // node's crypto lib

// 
// This is just to demonstrate how the shim layer would work, not provide a
// secure implementation of a shim via Node's `crypto` library. DON'T USE THIS.
//

function generate() {
    // https://nodejs.org/api/crypto.html#cryptocreatesecretkeykey-encoding
    const { publicKey, privateKey } = generateKeyPairSync('ed25519')
    return [publicKey, privateKey]
}
// etc.

and run

yarn link 'stellar-crypto'

Just as easily, they could use sodium-native as a shim, tweetnacl, noble, etc. The onus of choice would be on them, though we could provide some defaults, e.g.

yarn add @stellar/sdk @stellar/sdk-sodium-shim