rpc: Include more variations on fixtures for testing

[thanethomson]

Follows from discussion here: #604 (comment)

We need to evaluate the fixtures that we are testing for the RPC and see if we should add more variants for each case to ensure our serialization/deserialization is working as expected.

[thanethomson]

Reopening until we've used the RPC probe's output to update our tests.

[ebuchman]

Probe looks awesome. One note is that KVStore txs never error, so we won't be able to tests txs that fail with it. We could use the built in counter-app for that though.

Not sure what the best way is to exhaustively test all the possible responses. I guess some set of plans that flex many of the edges we can think of, and maybe additionally some fuzzing?

[ebuchman]

Oh as per #612 (comment) , probably a good idea to do this against Gaia

[thanethomson]

Not sure what the best way is to exhaustively test all the possible responses. I guess some set of plans that flex many of the edges we can think of, and maybe additionally some fuzzing?

Fuzzing may help a little, but I'm not sure it'd help too much when testing against the kvstore.

Oh as per #612 (comment) , probably a good idea to do this against Gaia

Definitely! How can I get hold of some raw JSON-RPC requests that I can send to a fresh Gaia node?

[ebuchman]

I guess it's just a matter of generating txs for the broadcast_tx endpoints, since everything else should be the same. We could use gaiacli for this, but not sure if there's a way to get it to dump the binary tx. Maybe @andynog has some ideas?