Add 3.x docker images

[farost]

Usage and product changes

Add a base Ubuntu image with CA certificates preinstalled for TypeDB 3.x.

Motivation

TypeDB Docker image required a stable base image with CA certificates.

Implementation

Split Ubuntu images into 2.x (the old image with JVM) and 3.x. Prepare scripts similar to 2.x for 3.x, but avoid using Bazel: it feels unnecessarily complicated, especially in the case of a multi-arch build.

Introduce a VERSION file for 3.x images to easily match multiple arch-specific images and the TypeDB Server requiring it.
Other reasoning for decisions is described in READMEs.

Now, to update all 3.x images, except for environment setup, you can just update the VERSION file locally and run a single script, which will do the whole work.

[typedb-bot]

PR Review Checklist

Do not edit the content of this comment. The PR reviewer should simply update this comment by ticking each review item below, as they get completed.

---

Trivial Change

• This change is trivial and does not require a code or architecture review.

Code

• Packages, classes, and methods have a single domain of responsibility.
• Packages, classes, and methods are grouped into cohesive and consistent domain model.
• The code is canonical and the minimum required to achieve the goal.
• Modules, libraries, and APIs are easy to use, robust (foolproof and not errorprone), and tested.
• Logic and naming has clear narrative that communicates the accurate intent and responsibility of each module (e.g. method, class, etc.).
• The code is algorithmically efficient and scalable for the whole application.

Architecture

• Any required refactoring is completed, and the architecture does not introduce technical debt incidentally.
• Any required build and release automations are updated and/or implemented.
• Any new components follows a consistent style with respect to the pre-existing codebase.
• The architecture intuitively reflects the application domain, and is easy to understand.
• The architecture has a well-defined hierarchy of encapsulated components.
• The architecture is extensible and scalable.

[krishnangovindraj]

Refactor suggestions to only duplicate the Dockerfiles and keep the infra unified.

[krishnangovindraj]

3.x tag in 2.x folder, no Dockerfile.amd64 in the picture.
Could you actually add one for each arch here?

In fact, the only differences between the two should be in the Dockerfiles ? Do we need to duplicate the rest of the files?

[farost]

Whoops, I forgot to remove this line after putting it there temporarily, thanks for the flag

The difference is in buildx (extended support for arch-specific images, but maybe it can work without -- I decided to prioritize moving forward), and other versioning. My priority was to make sure that the chosen platform was correct, while I still don't fully understand the usage of the 2.x images since it cannot be run on my machine.

[krishnangovindraj]

They're both basically doing the same thing.

FROM base-image
RUN apt update && ...

So they would both need buildx. Docker 2.x here is amd64 only at the moment, since we've never updated it to have both versions.

I don't see a reason to keep them separate. I can create the 2.x dockerfiles & test the images if you'd like.

[farost]

I can't run Bazel rules locally. It was partially a reason why I thought I'm not able to push both archs from my local machine:

bazel run //images/docker/ubuntu-2x:assemble-docker 
ERROR: /private/var/tmp/_bazel_spare/a5af50c3bc2e234514ed639efd623f2f/external/local_config_cc/BUILD:48:19: in cc_toolchain_suite rule @local_config_cc//:toolchain: cc_toolchain_suite '@local_config_cc//:toolchain' does not contain a toolchain for cpu 'darwin_arm64'
ERROR: /private/var/tmp/_bazel_spare/a5af50c3bc2e234514ed639efd623f2f/external/local_config_cc/BUILD:48:19: Analysis of target '@local_config_cc//:toolchain' failed
ERROR: Analysis of target '//images/docker/ubuntu-2x:assemble-docker' failed; build aborted: 
INFO: Elapsed time: 0.098s
INFO: 0 processes.
FAILED: Build did NOT complete successfully (1 packages loaded, 4 targets configured)
ERROR: Build failed. Not running target

But I can make two files for 2.x and reuse the new scripts from 3.x. I didn't know we really wanted it.