Re-implement serialization

[robknight]

Closes #195

Re-implements serialization based on the new refactored code.

Serialization format should be pretty similar to how it was before, with some small cosmetic changes.

I've had to implement a few more custom serialization functions, in order to avoid serializing middleware data. I've commented in the places where this was necessary, so that we can be aware that those custom serialization functions will not automatically track changes to the types in the way that Serde's attribute-based serialization does.

The new version has more tests, and in particular has an end-to-end test which:

• Serializes a SignedPod, and two quite different MainPods
• Generates JSON Schemas for SignedPod and MainPod
• Tests that the real SignedPod and MainPods can be validated at runtime using the schemas

[ed255]

LGTM! I've left two comments.
One is a small suggestion, the other is more a question/discussion.

[ed255]

this looks like a constructor with a different name :P
Will this method be used externally? If not, can we make it pub(crate)?

[robknight]

It does have to be public if we want users of the library to be able to deserialize SignedPods.

[ed255]

Won't users of the library interface the library through the frontend? And deserialize frontend::SignedPod (which internally deserializes MockSignedPod)?

[robknight]

Oh, sorry, you're quite right. I'll make it pub(crate).

[ed255]

What about deserializing a non-mock SignedPod?
Would this implementation have a switch here?

Same for the MainPod.

[robknight]

When I first wrote this, there were no non-mock SignedPods! Are the new non-mock Pods usable enough for me to implement serialization for them?

[ed255]

Both the non-mock SignedPod and MainPod should be ready enough to get serialization and deserialization :)
I would suggest doing that in another PR though.