If a user's ratings cannot be accessed, e.g. due to network errors, it
should skip to the next user.
Ideally we could mark a user as inactive after X failed retries.
We need to use the existing user from the DB to avoid overwriting the
user's secret or other details.
We also can't assert the user will stay the same, because at least
their name is allowed to change.
The UI should be built and served separately, not from within the
production container.
The tests should be run separately as well and are not needed from
within the production container.
When the import process finishes it can set progress to 100 multiple
times. The first call would add a stop time to the running progress,
but each further call with progress=100 would create another entry in
the table with stop already set.
This includes the code files in the docker image and creates a separate
data dir, which means we don't need to manually mount files into the
container anymore.
Removing the transaction will allow other (async) operations to succeed
while the import is running, otherwise the database will be locked.
It also actually speeds up the import process, and there's no good
reason to roll back if the import aborts mid run.
The two routes offer reloading the whole movie database from IMDb, and
reloading all users' IMDb ratings.
These functions (or very similar) were already available using the CLI,
but now they can be triggered remotely by an admin.
