light-client-verifier: reuse sign_bytes buffer

[mina86]

Rather than allocating a new vector each time canonical vote is encoded, allocate a vector in NonAbsentCommitVotes once and then reuse it each time sign_bytes are needed. This saves on doing multiple allocations and deallocations.

For overly verbose description of the length calculation:

• CanonicalVote. Note that length prefix doesn’t count bytes used for encoding the length, e.g. if the CanonicalVote message is 127 bytes than the length prefix is one byte and thus sign_bytes is 128 bytes. The table assumes all fields are set.

  |                 | tag | value |
  |-----------------+-----+-------|
  | (length)        |     |   1–2 | 2 if (length) is > 127
  | type            |   1 |     1 | SignedMsgType is at most 32
  | height          |   1 |     8 | The field is sfixed64
  | round           |   1 |     8 | The field is sfixed64
  | block_id        |   1 | 73–77 | See CanonicalBlockId below
  | timestamp       |   1 |  7—13 | See Timestamp below
  | chain_id        |   1 |   1+N | Assuming N < 128
  |-----------------+-----+-------|
  | (total)         |   105–116+N | If N≤13 than (length) is
  |                 |             | 1 byte and this is 115+N
  

• CanonicalBlockId.

  |                 | tag | value |
  |-----------------+-----+-------|
  | (length)        |     |     1 |
  | hash            |   1 |    33 | Assuming 32-byte hash
  | part_set_header |   1 | 37–41 | See CanonicalPartSetHeader
  |-----------------+-----+-------|
  | (total)         |       73–77 |
  

• CanonicalPartSetHeader.

  |                 | tag | value |
  |-----------------+-----+-------|
  | (length)        |     |     1 |
  | total           |   1 |   1–5 | Varint of u32; at most 5 bytes
  | hash            |   1 |    33 | Assuming 32-byte hash
  |-----------------+-----+-------|
  | (total)         |       37–41 |
  

• Timestamp. In unlikely event vote was made exactly at a second, nanos is zero and thus the field is not present. Assuming uniform probability of the nanos, in a bit over 73% of cases the filed will occupy it’s maximum size.

  |                 | tag | value |
  |-----------------+-----+-------|
  | (length)        |     |     1 |
  | seconds         |   1 |     5 | Assuming timestamps around now
  | nanos           | 0–1 |   0–5 |
  |-----------------+-----+-------|
  | (total)         |     |  7–13 |
  

---

• Referenced an issue explaining the need for the change
• Updated all relevant documentation in docs
• Updated all code comments where relevant
• Wrote tests
• Added entry in .changelog/

[romac]

Thanks a lot for the PR and the detailed explanations! Looks good, but I left a couple suggestions and believe we should increase the buffer size a little bit to err on the safe side, see my comment above.

[romac]

Thanks again so much for the PR!

[romac]

I will release all this in v0.36 later this week.