test: Add json marshal/unmarshal for test traces

[p-offtermatt]

Description

Closes: Part of #1265

The PR introduces a trace format that is just a JSON serialization of a step slice. This means it makes use of all the actions we already have.

• tests/e2e/tracehandler_testdata/ just contains the serializations of a few existing steps. These can be regenerated by this test:

  interchain-security/tests/e2e/trace_handlers_test.go

  Line 84 in e2175c2

  func TestWriteExamples(t *testing.T) {

• The serialization has two complicated aspects: Actions and proposals
  • JSON does not add types, so marshalling/unmarshalling interfaces is hard because they can contain different types
  • See http://gregtrowbridge.com/golang-json-serialization-with-interfaces/
  • I solve this by, on marshal/unmarshal, adding/reading an extra type string that contains the type of the action/proposal. unfortunately, these have to be maintained when we add new actions, but I don't see any easier way.
  • This is the reason for these two massive switch-cases:

    • interchain-security/tests/e2e/json_utils.go

      Line 50 in e2175c2

      case "main.submitConsumerAdditionProposalAction":

    • interchain-security/tests/e2e/json_utils.go

      Line 403 in e2175c2

      case "main.TextProposal":

To review this...

• check that in the _rapid_test.go files, the structs are built exhaustively, i.e. I didn't forget to add any fields that aren't populated now
• check that the switch-cases are exhaustive, i.e. no actions/proposals that exist are missed by the switch-case in json_utils.go
• take a look at the tracehandlers_testdata folder and see the json format, check if you see any obvious defects. viewing these is much nicer after either formatting them, putting them into a json viewer, ...
• check out the meat of the changes: the actual ser/de is done in tests/e2e/json_parser.go, tests/e2e/json_writer.go and tests/e2e/json_utils.go

---

Author Checklist

All items are required. Please add a note to the item if the item is not applicable and
please add links to any relevant follow up issues.

I have...

• Included the correct type prefix in the PR title
• Targeted the correct branch (see PR Targeting)
• Provided a link to the relevant issue or specification
• Reviewed "Files changed" and left comments if necessary
• Confirmed all CI checks have passed

Reviewers Checklist

All items are required. Please add a note if the item is not applicable and please add
your handle next to the items reviewed if you only reviewed selected items.

I have...

• Confirmed the correct type prefix in the PR title
• Confirmed all author checklist items have been addressed
• Confirmed that this PR does not change production code

[insumity]

Assume we add a new Action in the future. Based on this PR, I would assume we would need to modify a bunch of files to include this Action? What would be the process for that? Would it make sense to have a README.md file under tests/e2e to describe such a process (e.g., what files need to be changed, etc.)?

[p-offtermatt]

Assume we add a new Action in the future. Based on this PR, I would assume we would need to modify a bunch of files to include this Action? What would be the process for that? Would it make sense to have a README.md file under tests/e2e to describe such a process (e.g., what files need to be changed, etc.)?

yeah exactly. I'll draft up a README like that. I'll also put an issue in the backlog to look into setting up a static analyzer that could flag this. From all I can tell, the current solution is unfortunately the best I could find, so supporting it to be more smooth would probably be desirable.

EDIT: Added e837330

[insumity]

Great work! Thanks for the changes.

[sainoe]

Great work @p-offtermatt! See my comments.
Note that I haven't gone through everything yet, but I will cover the rest ASAP.

[shaspitz]

Great work! Added some comments w.r.t boilerplate and maintenance moving forward