Django 3.0 breaks lookupproxy, fix the version to <3.0

Closes #28

See merge request uis/devops/lookup/lookupproxy!29

.. to ensure container is built with latest version of django-ucamlookup & django-automationcommon

lookupapi: support users not of the form {scheme}:{identifier}

Although we run a postgres 9.6 server, the client will be whatever is
installed in the Travis VM. Ask Travis for a matching client.

The psycopg2 package is deprecated in favour of psycopg2-binary.

Lookupapi still had the implicit assumption that users would be named
{scheme}:{identifier} when created by django-automationoauth. That is
no-longer true and caused lookup proxy to fail when re-deployed.

With an abundance of caution, make sure we support all schemes we have
used historically until we're sure nothing will break if we remove them.

authentication: remove race condition in creating users

Previously we emulated a get_or_create user behaviour by attempting to
get the user and, if that failed, create it.

This introduced a race where another worker could create a user between
these checks. (We observed this in production when an initial log in
causes a flurry of requests to lookupproxy.) This was a result of
Django's autocommit mode since the user fetch and subsequent user
creation were separate transactions allowing for database change between
them.

The race-free approach is to *always* attempt to create the user and
only if that fails do we fetch the user. These are still run as separate
transactions but the user object will always be created by the first
worker to talk to the DB and the rest will see an integrity error
causing them to fetch the new user object.

add retries to OAuth2 HTTP(S) requests

Add a configurable number of retry attempts when fetching tokens from
the OAuth2 endpoint or when requesting resources authorised with OAuth2
tokens.

This uses requests' built-in retry behaviour which retries only in the
face of network errors such as DNS failures or connection errors. It
does not retry if data has made it to the server.

It is, unfortunately, non-trivial to write a test for this since faking
a network error requires deeper knowledge of requests internals than I
possess. We rely on the max_retries parameter behaving as documented.

Allow standard error from Django to be captured and reported by
gunicorn.

To enable easy testing of group memberships in development, default to
the test lookup instance in all but the production docker image where we
default to real lookup.

default to using production lookup

Defaulting to the test lookup instance was hurting us in testing since
people in test lookup tend to have incorrect institutions.

There's no downside to using production lookup by default and we can
re-visit this should we ever decide to offer write-access.

tox fix

fix files with flake8 violations

use shared consent app image

lookupproxy: allow trailing slash in ui URL

create self endpoint to get the getPerson information of the user logged in

The IAR backend allows both /ui and /ui/ for the swagger UI URLs. We
should be consistent.

Rather than copy-pasting the mock consent app into each application,
make use of a shared image.

Also includes a mockup service that will return the test lookup user mug99 when the scheme="mock". It still needs to modify the consent app to use scheme "mock" when using test raven.

misc correctness fixes

add basic packaging with Docker