Fix Raspi build and consolidate with normal build and image

[gloriousDan]

With this PR I try to fix the currently bad situation of docker images for the linux/arm/v7 platform.

We already discussed in the discord and I tried several different steps that all didn't work out:

First I tried installing the corresponding alpine packages like e.g. py-cryptography so that pip doesn't have to compile it.
That doesn't work, because the python:alpine image and alpines python package use different location for their packages (https://stackoverflow.com/questions/57435000/use-python-package-installed-with-apk-in-alpine-linux#57446376). Additionally, the python version and py-cryptography version depends on the used alpine version so we would loose direct control over these versions when using just an alpine image and installing alpine's python package. It would also be hard to assure that the dependency versions used in dev are the same as the ones used in the docker image.
Because of all these reasons I decided not to use any hacks to share packages between the different python installations as that would be very likely to break at some point.

In the past, we had problems with the raspi build because alpine shipped a very outdated version of rust (this is also mentioned in cryptography's install instructions https://cryptography.io/en/latest/installation/#alpine).

With the recent versions of alpine >= 3.15 this is not an issue anymore and in my tests with alpine v3.18 all packages compile just fine.

I tested the build without piwheels which takes about 1h 30 min
And with piwheels which runs a bit shorter at ~1h. Maybe caching could slim those times down a lot.

I also combined the docker images again because the piwheels repo is only included on armv7 anyway due to the architecture check and there's really no other reason to maintain both Dockerfiles.

I tested the images on amd64 and armv7 with emulation on my laptop and it seemed to work fine. But maybe you can release a beta image first so that some pi users can try it out.

I'm also pretty confident that it shouldn't break as often in the future because alpine now ships a new enough rust version. If needed we can still allow armv7 to fail in the build so that it doesn't mess with releases in case it breaks again.

[gloriousDan]

Actually there's one problem I get when starting the container it prints the following ERROR messages. Do you know if it is because of something wrong in the image or did I just mess up the build process for the test images?

chmod: /opt/recipes/mediafiles: No such file or directory
[2023-06-27 08:26:01 +0000] [1] [INFO] Starting gunicorn 20.1.0
[2023-06-27 08:26:01 +0000] [1] [INFO] Listening at: http://0.0.0.0:8080 (1)
[2023-06-27 08:26:01 +0000] [1] [INFO] Using worker: threads
[2023-06-27 08:26:01 +0000] [22] [INFO] Booting worker with pid: 22
[2023-06-27 08:26:01 +0000] [24] [INFO] Booting worker with pid: 24
[2023-06-27 08:26:01 +0000] [26] [INFO] Booting worker with pid: 26
ERROR failed to initialize plugins
ERROR failed to initialize plugins
ERROR failed to initialize plugins

[vabene1111]

no the error messages are as fine as error messages can be 😂 i added the plugin architecture for the open data project but it is just implemented to the degree where it works and not were its actually clean, you can safely ignore the messages.

I will merge this and release a beta, its easy enough to roll back in case anything breaks or if i need to release a hotfix.