WIP: Dockerize the server and its supporting services

[berkes]

This is a PR to discuss the solution to the issue with migrations.

It is unclear why the migrations keep failing, but they won't pass if the recipient_identifier is
a varchar(712). At least not in the dockerized version of mysql 8.4. It fails on creating the
index, as the index is larger than 3072.

The database is utf8, and collation is correct.

When we set this column to be only 512 long, as it is at the end of running all migrations anyway,
the index can be created.

The failure is:

  Applying issuer.0043_auto_20180614_0949... OK
  Applying issuer.0044_auto_20180713_0658...Traceback (most recent call last):
  ...
MySQLdb.OperationalError: (1071, 'Specified key was too long; max key length is 3072 bytes')

This PR proposes two alternative solutions to this:

1. Remove the index creation from issuer.0043_auto_20180614_0949 and add it in a new migration at the end
2. Modify existing migrations and ensure the recipient_identifier is varchar(512).

The option 1 was reverted and can only be witnessed in the git history of this PR. It has a severe
downside: production builds, and other builds will run this new migration, but
will fail, as the index exsists. Neither MySQL nor django migrations have a
mechanism to "CREATE INDEX .. IF NOT EXISTS" like postgres or mariadb do.

Option 2 has downside that it alters migrations that have already been applied. Which is normally
a bad practice.

• fix: Fix unclosed quote in example env var file
• fix: Add compound index when the indexed columns have the right size
• feat: Docker compose with required services
• Revert "fix: Add compound index when the indexed columns have the right size"
• fix: Allow migrations to create indexes that are guaranteed to be under 3072