WebAuthn key format

[edmundnoble]

This PR allows WebAuthn keys in keysets.

Public keys of different formats are distinguished by their prefix.

• Ed25519 keys have no prefix
• Public keys for WebAuthn appearing in keysets must be prefixed with "WEBAUTHN-".

The new enum DynKeyPair ranges over Ed25519 keypairs and WebAuthn keypairs. Our client-side function for building commands (mkCommand, mkCommand') have counterparts that accept DynKeyPair instead of Ed25519KeyPair: mkCommandWithDynKeys. The new command generators will perform different signing algorithms and produce different signatures, depending on the type of keypair used. This distinction is only meaningful in tests, because real users will never have a WebAuthn private key. Real users using WebAuthn-signed transactions would be using a web client and an authenticator device that hold the secret key on the user's behalf.

The PR adds a lot of new functions for generating, parsing and printing WebAuthn keys. The functions applying to WebAuthn private keys are only used for testing.

The following repl session demonstrates that "WEBAUTHN-" prefixed keys pass format enforcement and are usable as keyset guards:

pact> (env-exec-config ["EnforceKeyFormats"])
["EnforceKeyFormats"]
pact> (env-data {"k": ["WEBAUTHN-a4010103272006215820c18831c6f15306d6271e154842906b68f26c1af79b132dde6f6add79710303bf"]})
"Setting transaction data"
pact> (env-sigs [{"key": "WEBAUTHN-a4010103272006215820c18831c6f15306d6271e154842906b68f26c1af79b132dde6f6add79710303bf", "caps": []}])
"Setting transaction signatures/caps"
pact> (enforce-keyset (read-keyset 'k))
true

PR checklist:

• Test coverage for the proposed changes
• PR description contains example output from repl interaction or a snippet from unit test output
• Documentation has been updated if new natives or FV properties have been added. To generate new documentation, issue cabal run tests. If they pass locally, docs are generated.
• Any changes that could be relevant to users have been recorded in the changelog

Additionally, please justify why you should or should not do the following:

• Confirm replay/back compat
  • (I am running a partial replay back to when webauthn sigs were enabled on mainnet)
• Benchmark regressions
  • Seems unnecessary
• (For Kadena engineers) Run integration-tests against a Chainweb built with this version of Pact

[edmundnoble]

This instance seemed unused, and it's very risky to provide this instance, but I don't want to break downstream if I don't have to.

[edmundnoble]

@jmcardon do you want this instance back? If so maybe we should write up a ticket for adding this back and using an explicit definition instead of using deriving.

[edmundnoble]

@jmcardon do you want this instance back? If so maybe we should write up a ticket for adding this back and using an explicit definition instead of using deriving.

[imalsogreg]

LGTM