Specify and implement CBOR deterministic encoding of `[]Screen`

[amaury1093]

Part of #11970
See TODO in https://github.com/cosmos/cosmos-sdk/blob/main/docs/architecture/adr-050-sign-mode-textual.md#signdoc

[JimLarson]

Here's a first cut:

;;; CDDL (RFC 8610) Specification of SignDoc for SIGN_MODE_TEXTUAL.
;;; Must be encoded using CBOR deterministic encoding (RFC 8949).

;; A Textual document is an array of screens.
screens = [* screen]

;; A screen consists of a text string, an indentation, and the expert flag,
;; represented as an integer-keyed map. All entries are optional.
;; Text defaults to the empty string, indent defaults to zero,
;; and expert defaults to false.
screen = {
        ? text_key: tstr,
        ? indent_key: uint,
        ? expert_key: bool,
}

;; Keys are small integers to keep the encoding small.
text_key = 1
indent_key = 2
expert_key = 3

Deterministic encoding in this context means:

• "screens" must be a definite-length array, specifying the size up-front;
• map entries must occur in order of ascending key value;
• keys and map length are given in their single-byte encoding;
• screens array and text string length are given in their shortest encoding;
• map entries with the default value will be omitted.

Here's some options that were considered:

• Could have made a screen a record (array) instead of a struct (map), but general advice is that structs are more flexible and future-proof. A map with default values for omitted entries seems like the best way to be able to evolve the format without requiring simultaneous upgrades of chain and device software.
• Could have used strings for struct keys, but doesn't actually make the encoding more flexible, takes up more room with repeated strings.
• Could have required at least one screen or non-empty text, but seems like extra verbiage and checks for no real benefit.

Example: Using the example in ADR-050 (with comments removed and some details added):

Chain ID: simapp-1
Account number: 10
*Public Key: A395B24FE2005
Sequence: 2
This transaction has 1 message:
Message (1/1): bank v1beta1 send coins
From: cosmos1abduwerabsnf8923482
To: cosmos129834skjhdfknciuwha
Amount: 10 atom
End of transaction messages
Fee: 0.002 atom
*Gas: 100'000
*Hash of raw bytes: A83B2D502FE233

This would be encoded as follow, using the diagnostic notation of RFC 8949:

[
        {1: "Chain ID: simapp-1"},
        {1: "Account number: 10"},
        {1: "Public Key: A395B24FE2005", 3: true},
        {1: "Sequence: 2"},
        {1: "This transaction has 1 message:"},
        {1: "Message (1/1): bank v1beta1 send coins"},
        {1: "From: cosmos1abduwerabsnf8923482"},
        {1: "To: cosmos129834skjhdfknciuwha"},
        {1: "Amount: 10 atom"},
        {1: "End of transaction messages"},
        {1: "Fee: 0.002 atom"},
        {1: "Gas: 100'000", 3: true},
        {1: "Hash of raw bytes: A83B2D502FE233", 3: true}
]

(Map entries would be encoded in the order presented.)

Question: is there any other use of CBOR in the Cosmos ecosystem? If so, which Golang CBOR package is used?

[amaury1093]

Question: is there any other use of CBOR in the Cosmos ecosystem? If so, which Golang CBOR package is used?

We can also consider not using any library. Just write an encoder for []Screen that happens to be CBOR compatible. It would be like 100LOC max?