Introducing calltable serialization to TransactionV1 structures subtree.

[zajko]

This is an extension to the bytesrepr serialization used in the rest of the node and it also uses the FromBytes and ToBytes traits.
From now on selected types will use a specific serialization approach which will be called "calltable" serialization.
A "calltable-serialized" type is serialized as follow:

• For structs:
  • Given type X with N attributes we assign a unique (in the scope of X) u16 index to each of the structs attribute. The assumption is that the indexes are 0-based
  • We serialize each of the structs attribute using it's ToBytes implementation, producing binary payloads: binary_vec₀, binary_vec₁, ..., binary_ve
    c_N-1. We don't allow any of the binary_vec_i to be empty.
  • We construct a bytes vector which is a concatenation of binary_vec₀, binary_vec₁, ..., binary_vec_N-1
  • We construct a fields vector. The i-th element of fields is a description of the i-th attribute:
    • For field with index 0 this description will be:
      field₀ = Field {
      index: 0
      offset: 0
      }
    • For each next field:
      field_i = Field {
      index: i
      offset: field_{i - 1}.offset + length(binary_vec_{i - 1})
      }
  • We construct an instance of CalltableSerializationEnvelope {fields, bytes} and serialize it using it's ToBytes implementation.
• For enums:
  • Given an enum E with M variants we assign a u8 unique index for each of the variant. The variant-index should start from 0 and be contiguous.
  • Given an enum instance e of variant E_j (having variant index j) which has N attributes:
    • we assign a unique (in the scope of *E_j) u16 index to each of the enum variants attribute. The assumption is that the indexes are 1-based.
    • We serialize value of j as binary_vec₀ and each of e attribute as subsequent binary_vec (binary_vec₁, binary_vec₂,..., bi
      nary_vec_N). We don't allow any of the binary_vec_i to be empty.
    • We construct a bytes vector which is a concatenation of binary_vec₀, binary_vec₁, ..., binary_vec_N.
    • We construct a fields vector. The i-th element of fields is a description of the i-th attribute:
      • For field with index 0 this description will be:
        field₀ = Field {
        index: 0
        offset: 0
        }
      • For each next field:
        field_i = Field {
        index: i
        offset: field_{i - 1}.offset + length(binary_vec_{i - 1})
        }
    • We construct an instance of CalltableSerializationEnvelope {fields, bytes} and serialize it using it's ToBytes implementation.
    • To recap, each enum variant we serialize analogously to a struct, but we prepend a synthetic u8 field which identifies the variant.

This PR applies calltable serialization to the following types:

• InitiatorAddr enum
• PricingMode enum
• TransactionEntryPoint enum
• TransactionInvocationTarget enum
• TransactionScheduling enum
• TransactionTarget enum
• TransactionV1 struct
• TransactionV1Body struct
• TransactionV1Header struct

All other types (especially legacy ones, including those nested in "calltable-serialized" types) should use "regular" serialization logic.

[zajko]

The gas values changed here because:

• A new public function was introduced in types (allocate_buffer_for_size)
• InitiatorAddr is used and passed to the engine and it's serialization schema changed

[darthsiroftardis]

bors r+

[casperlabs-bors-ng]

Build succeeded:

• continuous-integration/drone/push