Operational certificate + pool cold key derivation

[refi93]

Motivation: Add instructions for derivation of pool cold keys and operational certificate signing.

Changes:

• introduced getExtendedPoolColdPublicKey(coldKeyPath) call - the expected derivation path structure is m/1853'/1815'/0/<cold key index>'
• introduced signOperationalCertificate(kesPublicKeyHex, kesPeriod, counter, coldKeyPath) which assembles the operational certificate and returns its signature - as the OpCert structure has no variable length fields and is well under 255 bytes, it's done in a single APDU
• the security policy both for key derivation and operational certificate signing validates the coldKey derivation path
• refactored messageSigning.c to have a common function for signing a message with a key derived from a path and purpose-specific functions for tx witnesses and operational certificate signatures with corresponding message structure and derivation path validation, to ensure pool cold keys are not used for tx witnesses and vice-versa to prevent even hypothetical collisions between the different types of messages (txs vs operational certificates) being signed by those keys
• refactored bip44_hasValidCardanoPrefix() into bip44_hasValidCardanoWalletPrefix() to introduce equivalent function for pool cold keys named bip44_hasValidCardanoPoolColdKeyPrefix() - which is technically not required to have but I see it as good for readability and consistency, making it clear to a casual reader of the codebase that pool cold keys and wallet keys are logically separate
• added str_formatUint64() helper function which prints uint64 integers in decimal representation
• added TRACE_UINT64 debugging macro to trace uint64 values like issueCounter or kesPeriod

Testing:

• ran integration tests from Operational certificate signing and cold key derivation ledgerjs-cardano-shelley#15

yarn test-integration --grep signOperationalCertificate
yarn test-integration --grep getExtendedPoolColdPublicKey

TODO: add docs (to be added once high-level idea is validated)
TODO2: missing flag in makefile to separate operator functionality (IMHO worth doing after we merge the with the rest of functionality)

[janmazak]

Overall, I quite like it.

The only major problem is displaying uint64_t, again.

Perhaps we should push ledger to fix it and support it properly in snprintf.

[janmazak]

This should be allowed only for the operator app.

See 8ff1652 on branch operatorapp. All the code should be included only under the flag, too. (That is not a definitive solution, just a first attempt, so feel free to improve it.)

[refi93]

I'd rather not introduce the flagging of features here as the solution is not final yet, so it is likely to result in unnecessary conflicts (and once finalized, should be easy to apply). Maybe I would call the flag HAVE_OPERATOR_FEATURES to be consistent with similar flags for U2F (HAVE_U2F) and WebUSB (HAVE_WEBUSB)

[refi93]

the current version of the getPoolColdPublicKey call is returning the non-extended public key - I realized that even though it should technically be enough, it's likely to cause "pain" with the hw cli which internally deals with extended public key (especially in the hw signing file) and existing wallet implementations also likely use extended public keys in their internal logic, so this would only force them to introduce special code for cold keys.

TLDR - TODO rework getPoolColdPublicKey call to return the extended public key

[refi93]

TODO - update cold key derivation to comply with CIP-1853: cardano-foundation/CIPs#56 (i.e. change cold key usecase index to hardened)

[janmazak]

Will be included as part of another PR.