fix: use TARGETARCH instead of TARGETPLATFORM in user Dockerfiles

[stasadev]

The Issue

From Drupal Slack https://drupal.slack.com/archives/C5TQRQZRR/p1731341586120089

Waiting for containers to become ready: [web db] 
Warning: command 'bash -c mkdir -p /tmp/sqlite3 && wget -O /tmp/sqlite3/sqlite3.deb https://snapshot.debian.org/archive/debian/20240203T152533Z/pool/main/s/sqlite3/sqlite3_3.45.1-1_arm64/v8.deb && wget -O /tmp/sqlite3/libsqlite3.deb https://snapshot.debian.org/archive/debian/20240203T152533Z/pool/main/s/sqlite3/libsqlite3-0_3.45.1-1_arm64/v8.deb && apt-get install -y /tmp/sqlite3/*.deb && rm -rf /tmp/sqlite3' run as 'root' failed with exit code 8:
--2024-11-11 16:30:05--  https://snapshot.debian.org/archive/debian/20240203T152533Z/pool/main/s/sqlite3/sqlite3_3.45.1-1_arm64/v8.deb
Resolving snapshot.debian.org (snapshot.debian.org)... 185.213.153.170
Connecting to snapshot.debian.org (snapshot.debian.org)|185.213.153.170|:443... connected.
HTTP request sent, awaiting response... 404 NOT FOUND
2024-11-11 16:30:05 ERROR 404: NOT FOUND. 

Looking at that URL, I suspect that the Docker build engine is using arm64/v8 as the target platform, which makes sense, but that maybe makes the URL of the SQLite .deb wrong.
If I remove the /v8 from that URL in my browser, it actually tries to download something.
Is there a way I can override the TARGETPLATFORM build argument in .ddev/config.yaml to force it to be arm64 , as a workaround?

From https://ddev.readthedocs.io/en/stable/users/extend/customizing-images/#adding-extra-dockerfiles-for-webimage-and-dbimage, it looks like maybe the workaround that installs SQLite should be using TARGETARCH instead of TARGETPLATFORM.

How This PR Solves The Issue

Uses TARGETARCH in the user Dockerfile, this change is also important for the newly added 'install_php_extensions.sh'

Manual Testing Instructions

Should pass the tests.

Automated Testing Overview

Release/Deployment Notes

[phenaproxima]

Can confirm in manual testing that this worked.

[github-actions]

Download the artifacts for this pull request:

• all-ddev-executables.zip
• ddev-macos-amd64.zip
• ddev-macos-arm64.zip
• ddev-linux-arm64.zip
• ddev-linux-amd64.zip
• ddev-windows-amd64.zip
• ddev-windows-amd64-installer.zip
• ddev-windows-arm64.zip
• ddev-windows-arm64-installer.zip

See Testing a PR.

[stasadev]

@rfay, I also want to point out that snapshot.debian.org can be fragile, I hit this problem with ddev-python2 add-on (the link was not available for 2 days, until I "fixed" it by downloading python2 from ftp.debian.org):

• Unable to install add-on 503 Service Unavailable ddev-python2#2

At that time I checked sqlite3.45.1 - it worked, and I forgot about it until today.

1. Maybe we need to bundle the sqlite3.45.1 deb files to ddev-webserver, similar to this:

ddev/containers/ddev-webserver/Dockerfile

Lines 70 to 75 in 924ad6f

	# Install older mariadb client and mariadb-dump into /usr/local/mariadb-old/bin
	# to solve variety of problems with newer mariadb-dump.
	RUN if [ "$(dpkg --print-architecture)" = "arm64" ]; then cd /tmp && curl -L -s --fail -O "https://dlm.mariadb.com/3607865/MariaDB/mariadb-10.11.6/repo/debian/pool/main/m/mariadb/mariadb-client_10.11.6+maria~deb12_arm64.deb" -O "https://dlm.mariadb.com/3607494/MariaDB/mariadb-10.11.6/repo/debian/pool/main/m/mariadb/mariadb-client-core_10.11.6+maria~deb12_arm64.deb"; fi
	RUN if [ "$(dpkg --print-architecture)" = "amd64" ]; then cd /tmp && curl -L -s --fail -O "https://dlm.mariadb.com/3607675/MariaDB/mariadb-10.11.6/repo/debian/pool/main/m/mariadb/mariadb-client_10.11.6+maria~deb12_amd64.deb" -O "https://dlm.mariadb.com/3607123/MariaDB/mariadb-10.11.6/repo/debian/pool/main/m/mariadb/mariadb-client-core_10.11.6+maria~deb12_amd64.deb"; fi
	RUN set -x && cd /tmp && for item in *.deb; do dpkg-deb -x ${item} extracted; done
	RUN mkdir -p /usr/local/mariadb-old/bin && cp -ap /tmp/extracted/usr/bin/{mariadb,mariadb-dump,mysql,mysqldump} /usr/local/mariadb-old/bin

It will add +1250 KBytes to the image:

.rw-r--r-- 894k stas stas 2024-02-04 17:21 libsqlite3-0_3.45.1-1_amd64.deb
.rw-r--r-- 835k stas stas 2024-02-04 17:21 libsqlite3-0_3.45.1-1_arm64.deb
.rw-r--r-- 374k stas stas 2024-02-04 17:21 sqlite3_3.45.1-1_amd64.deb
.rw-r--r-- 364k stas stas 2024-02-04 17:21 sqlite3_3.45.1-1_arm64.deb

2. Or we can pre-download it somewhere on GitHub, and change the download link (this is what I did in ddev-python2).

3. Or leave it as it is, because Debian Trixie will most likely be available in 8-10 months https://wiki.debian.org/DebianReleases

Let me know what you think about it.

[rfay]

Now that we sorted out what we were chasing, I think TARGETARCH might have been arm64/v8. But then when he tested the PR it would have failed the same way.

(He had an ancient Colima with an ancient docker server version in it, that apparently passed TARGETPLATFORM=linux/arm64/v8)

As far as I can tell, TARGETPLATFORM in this context should only have been linux/amd64 or linux/arm64.

That doesn't mean that this PR is less correct. It's more elegant for sure.

[rfay]

I think we should go with this because it's simpler and more elegant.