R4R: Use iota where appropriate

[jackzampolin]

Ref: #3621 (comment)

• Linked to github-issue with discussion and accepted design OR link to spec that describes this work.
• Wrote tests
• Updated relevant documentation (docs/)
• Added entries in PENDING.md with issue #
• rereviewed Files changed in the github PR explorer

---

For Admin Use:

• Added appropriate labels to PR (ex. wip, ready-for-review, docs)
• Reviewers Assigned
• Squashed all commits, uses message "Merge pull request #XYZ: [title]" (coding standards)

[jackzampolin]

Looks like that bonding test is still flapping...

[codecov]

Codecov Report

Merging #3632 into develop will decrease coverage by 0.01%.
The diff coverage is 0%.

@@             Coverage Diff             @@
##           develop    #3632      +/-   ##
===========================================
- Coverage    61.28%   61.26%   -0.02%     
===========================================
  Files          186      186              
  Lines        13998    13998              
===========================================
- Hits          8578     8576       -2     
- Misses        4876     4878       +2     
  Partials       544      544

[cwgoes]

I understand this is a Go idiom, but I actually think it makes these files harder to read - now, if you want to figure out the byte for a particular vote option or proposal type, you have to count lines. Furthermore, we're likely to want to add additional types in the future, and probably want to keep the same mappings, which is easy to accidentally undo with iota.

So I would vote not to do this, in these instances and in general. cc @rigelrozanski Any thoughts?

[alexanderbez]

I don't see anything inherently wrong with these changes.

now, if you want to figure out the byte for a particular vote option or proposal type, you have to count lines.

Can you provide some context and examples of when you'd actually want this? Do we provide these exact bytes to any clients or is it only used internally? If the latter, then it doesn't really matter imho.

[cwgoes]

Can you provide some context and examples of when you'd actually want this? Do we provide these exact bytes to any clients or is it only used internally? If the latter, then it doesn't really matter imho.

They're used in stored values, which we will want to upgrade in a forwards-compatible way (so we don't have to modify the old state), and which a client might want to decode (e.g. for lite client proof verification). As far as I can tell none are used in transaction tags at present, although we might want to use them there in the future.

I don't have that strong an opinion on this, so if the general consensus is that it increases code readability I'll approve.

[alexanderbez]

Ok, well if want want easy upgradability, then I renege my comment/approval here.