Design an improved migration system

[artoonie]

In order to support old config files, deserializable objects in our codebase currently contain all previous fields. This creates clutter, is hard to test, and will lead to bloat as more changes come and more fields change.

Possible solutions include either create versioned objects, or (what we do now) support all deprecated fields forever. I prefer the latter, because versioned objects lead to a lot of duplicated code.

We should design an improved migration system. It should take a versioned config file and "upgrade" it to the latest format. It could work on raw JSONs or on versioned objects, but either way, it should be a separate module that keeps objects used in tabulation clean and free of deprecated files.

For example: https://github.com/BrightSpots/rcv/issues/628 We should get rid of code in the deserialized RawContestConfig: https://github.com/BrightSpots/rcv/blob/develop/src/main/java/network/brightspots/rcv/RawContestConfig.java#L258

Output of this Issue is another prioritized, estimated issue with a clear design plan and prioritization. Requirements should include tests of the migration system.

[HEdingfield]

Additional context on this: I messaged @artoonie:

been wondering... we have // Migrations from 1.3.0 to 1.4.0 in one of our methods... do we not need to add code to alias in there? And, if it makes sense to do that, can we get rid of the setCode in RawContestConfig?

And his response pointed to this issue:

Sadly, no -- the migrations require the objects to fully deserialize into RawContestConfig. More here: https://github.com/BrightSpots/rcv/issues/706