Gitlab ci without compose

What does this MR do?

Removes using custom docker containers in CI. Here, I chose a different way from !1542 (closed) to try gitlab ci service containers, which should mostly provide the same functionality as docker-compose.

In the process, I introduce some changes that put more things from scripts into the application:

• Creating folders the application needs

(This change can be forwarded to the dev-setup as well, but I would keep it separate for now; as well, I got rid of the CI environment completely, there might be leftovers to be cleaned up.)

The only drawback is, that the download folder of selenium is not accessible from CI anymore. Solutions could be to use a custom image that stores the downloads to a subfolder of /build/foodsharing-dev/foodsharing (or maybe use an environment variable, seems a bit odd to hardcode project related directory structure in a docker image) which is shared between all services and the "build" container. I don't consider the effort worth for now and just disabled the file download tests.

Main effect of this change is a huge speedup in CI runtime (tests in ~9-10 instead of ~15-17 minutes) as well as the possibility to run different test containers concurrently. Also, it uses much less system resources because we are not building docker images each time... (The SSD wear level counters are increasing quite rapidly, still not too worrying)

How confident are you it won't break things if deployed?

I try to not change code... Let's see

Checklist

• added a test, or explain why one is not needed/possible...
• no unrelated changes
• asked someone for a code review
• joined #foodsharing-beta channel at https://slackin.yunity.org
• added an entry to CHANGELOG.md (description, merge request link, username(s))
• Once your MR has been merged, you are responsible to update the #foodsharing-beta Slack channel about what has been changed here. They will test your work in different browsers, roles or other settings