Review test data/fixtures

[chris48s]

The suite of test data we've got for creating various conditions we need to test against is functional, but it needs tidying.

• There are some example responses that are a straight copy of a response from the API sandbox
• There are some example responses that only exist in this repo and are assembled to create a somewhat contrived condition (e.g: we don't have a 'home' point)
• There are some example responses that are a dump of a real response which recreates some condition but also contains a bunch of extraneous data (e.g: addresses in picker that don't map to an example address response, or many candidate objects which aren't relevant to the polling station-based condition we're interested in)
• There are various cases where we're using a slightly strange choice of fixture for testing purposes. For example, there are a number of tests where we're relying on SS30AA (which reproduces that quite specific condition of a countermanded poll) as the fixture for "station not found".
• We may need to recreate additional conditions (e.g: party list elections) as we work on adding candidate data ahead of next May's elections.

We've done a reasonable job of not allowing this to spiral out of control in #281 but we could usually further review and tidy up the test data with the intent of:

• Minimizing maintenance of the example responses over time
• Making the intent of the integration tests super-clear

[chris48s]

Another thing to think about here:

Sometimes we need several multiple slightly different versions of the same test fixture. Instead of having several different copies of the same thing with one value changed, can we either generate/template it, or monkey-patch it?

[chris48s]

While looking at this, it is also worth noting that the test fixtures here should be updated to reflect the current upstream API responses as there have been some minor upstream API changes (e.g: nation property).. and possibly more on the way? You'll know better than me..