Pins all the build dependencies required by poetry, otherwise
poetry installs arbitrary versions of them, which leads to a wrong
version of cryptography being installed and the build failing.
Note that Cloud dependencies (pillar and the like) has to have their
build dependencies pinned in the same exact manner, for the same reason.
Pins all the runtime dependencies as well, because Cloud can only use
poetry==1.0 due to its source dependencies, so there's no
"poetry lock --no-update" and each "poetry lock" updates arbitrary packages.
Having a virtualenv in `.venv` is very convenient because many tools
automatically pick up on it. However, this then also happens during the
construction of the Docker images, which subsequently breaks.
Until a proper fix is found, it's easiest to just put the virtualenv
outside of the project.
This is where the representation of the design system will reside.
When the application runs in production (with DEBUG = False) the url
will return 404.
WHEELHOUSE: since we're defining the variable we might as well use it.
DOCKER_IMAGE_NAME: introduced to prevent duplications of the name, and to
add a little confirmation message when the script is done.
Because pillar-python-sdk doesn't have a `production` branch, it was always
using `master`. Now it's only using `master` if `STAGING_BRANCH`=`production`.
The HAproxy docker image we were using is no longer maintained (hasn't been
for years), but is built upon Alpine Linux which has a big security leak:
https://talosintelligence.com/vulnerability_reports/TALOS-2019-0782
The security leak is fixed in this build of the docker image, but we should
move to something else (lke Træfik).
