Crypto efficiency improvements

[jwrosewell]

Performance

The performance of the crypto algorithm is somewhat proportional to the amount of data provided. There is an opportunity to improve efficiency and performance by modifying the signing-definition.ts code and the associated documentation. This issue lists the areas for consideration.

1. Byte arrays. Assemble the data for signing in a byte array rather than an array of strings. This is the most significant improvement.
2. Separator. Rather than using a 2 byte separator use a 1 byte separator.
3. Integer timestamp. Add the integer value of the timestamp to the byte array and not the string representation.
4. Signatures. Convert the signatures from base64 strings back to byte arrays before adding them.
5. UUID. Where values are UUIDs then convert them to 16 byte format rather than string representation.
6. Enumeration of preference types. Rather than use a string to represent the preference types a single byte could be used.
7. Avoid JSON. Don't turn the data structure into JSON before signing.
8. Split Preferences and Identifiers. The identifiers are included in the preferences data when the preferences are signed. There is not logical requirement to do this.

Simplicity

The current implementation uses JavaScript features associated with strings to assemble the data rather than byte arrays and byte buffer methods. This results in lengthy data for signing that can be avoided as described previously.

An additional problem is becomes apparent when implicating the algorithm in other programming languages. For example Go or .NET either lack comparable methods or when they have comparable methods result in subtly different byte arrays and therefore signatures.

Modifying the documentation and JavaScript reference to make the assembly of the input data for the signatures crystal clear and efficient will help reduce complexity across the OneKey eco-system.

The tests performed in Go suggest a 50% reduction in the amount of data passed for signing and verification will result in a 5% improvement in signing and 10% improvement in verification. The changes are simple to make at this stage of the project but a lot harder once live deployments start.

[jwrosewell]

The following PR initially for the documentation addresses this issue - OneKey-Network/addressability-framework#197.