ci: run SDK tests against latest version of API

[redshiftzero]

the idea in this PR is to add a circle CI job that runs nightly and (I can be convinced the latter is a bad idea) on each PR. the circle CI job will run the API tests against the server container

that way if there's a discrepancy between API and SDK, we can detect it (ref: #55)

(btw I did this in a fork so that my frequent force pushing doesn't create a billion notifications)

[redshiftzero]

btw the tests here are running against the server in CI, the issue is that some tests change state (i.e. deleting sources/submissions) - that's the remaining work here before this is ready for review

[redshiftzero]

OK this is working and ready for review. Once this is approved I'll update the required CI jobs for merge. Note that the diff looks big here, but this is mostly VCR cassettes getting updated.

What I think we want to do next - ideally in a followup since what's here so far is a concrete step forward testing-wise - is:

0. Add to the developer documentation (ref: Add developer documentation #6) the update process for the Qubes RPC JSON files (I have not updated those test cases in this PR nor afaict has anyone since the time they were added).
1. DRY up the TestAPI and TestAPIProxy test classes if we can - we have basically duplicated tests in two files with different decorators on them.

[heartsucker]

This might not be enough time. Building the dev container is slooooooooow.

[redshiftzero]

haha, it feels like it takes a long time but it "only" takes around 4-5 minutes

[heartsucker]

Nit: missing newline at EOF

[heartsucker]

DRY up the TestAPI and TestAPIProxy test classes if we can - we have basically duplicated tests in two files with different decorators on them

The follow up should also include an env var / CLI opt to ignore the cassettes that way we don't have to do an rm data/*.yml ; make test ; git checkout -- data/ to "reset" everything. This could be in the decorator.

[kushaldas]

Other than the one question, rest looks great. Thank you 👍 Approved.

[kushaldas]

Why are we going back to an older release?

[redshiftzero]

We specify in our Pipfile Python 3.5 (and in my local dev env I use pyenv to use only that version). However in yarl 1.2.1 they pinned the minimum Python version to be 3.5.3. So this can cause confusing local failures for developers if they're using Python 3.5.0, so I set it back to 1.2.0 for compatibility with all Python 3.5.* since there were no security updates in the diff from yarl 1.2.0 to yarl 1.3.0.