Avoid using `string` fields for binary data

[jasonpaulos]

Summary

Recently the field Logs []string was added to EvalDelta. This field is meant to hold arbitrary binary data, but because it was declared with []string, when encoding into JSON the data is interpreted as UTF-8. If instead it were declared as [][]byte, our encoder would base64 encode the contents when encoding into JSON. For this reason, it's necessary to use []byte over string for binary data in all cases.

Scope

• Add a unit test which uses reflection and recursion to examine all fields referenced from bookkeeping.Block. If the field is a string and we don't have a specific exception for it, error. This will prevent us from accidentally adding string fields going forward.
• For existing string fields, create exceptions so the test passes with the current structs. However, investigate whether converting these fields to byte slices has any effect on their msgpack encoding -- if not, then convert them to byte slices to eliminate all strings from the structs.
  • Msgpack uses different byte prefixes to distinguish between strings and binary data, so we cannot migrate the existing string instances to []byte without changing the canonical encoding of these structures.

[tolikzinovyev]

Great idea!

[tsachiherman]

just an idea - consider implementing the unit test by extending algofix.
this tool already scan the codebase and applying few "things".

If you want to add exceptions, you can add these as struct tags / directives.
( admittedly, it could be more complicated that absolutely needed by this issue )

[jasonpaulos]

I was not aware of algofix, that's very interesting.

In this specific case it ended up being fairly straightforward to use reflection to find all referenced types from bookkeeping.Block, but I will remember algofix for future use cases.