Deleting the existing parity check results can be slow as they can be very
large records in the database. We don't care about callbacks or validation
here, so we can optimise the deletion with `delete_all`.

We need to be able to request an individual resource as part of the parity
check. The difficulty with this is that we need a valid ID for each lead
provider. Instead of specifying these manually, I've opted to allow dynamic
substitution by evaluating code from the YAML file.

We can now specify an ID attribute in the path with `:id` and a corresponding
option in the YAML file that, when evaluated (in the context of the `Client`)
should return a valid id for the lead provider.

Add all the listing and individual GET resource endpoints to the YAML file.

The CSV responses are very large and cause issues when trying to insert into
Postgres. To be able to include them for now we are converting the response CSV
to a hexdigest that can be stored and compared. If we want more details we will
have to make the requests manually to inspect the responses.

In order to finish the parity check as soon as possible, we stop paginating
responses as soon as we encounter a discrepency. A mismatch in a earlier page
is likely to effect later pages anyway, so this is all we will be interested in
(and other issues would be surfaced on future runs when its fixed).

These cause issues with timeouts on the database; I'm not sure why as we hash
the large CSV response so it shouldn't cause issues.

Remove CSV endpoints; if we want to include them we can add another ticket to
make them work.

As the id we grab for the lead provider is random, we need to persist it in the
`ResponseComparison` to be able to replicate the request.

Add `id` to `request_path` before saving (avoids adding a new attribute to
`ResponseComparison`).

When we output the JSON diff we want to pretty format it or we end up with a
single line which is hard to compare.

If the response is JSON we deep sort the resulting hash so that we can compare
the contents irrespective of order (as the new serializers in NPQ reg may
serialize the fields in a different order).

Instead of evaluating the YAML contents directly, we can specify a method in
the YAML file and call in the `Client`. This also has the benefit of being able
to more easily test the possible `id` options.