Fix broken migrations and Docker startup

Fix broken and blocking migration file

V1_120__sps_2018 fails because some of the rows for study_program_subject.subject_id contain references to invalid/non-existent subjects, which blocks all subsequent migrations.

This is shown in the 4 following subject codes, and usually the problem narrows down to a F23 subject not existing in F18 or having a different code:

• F18L3W200 - doesn't exist, but F23L3W200 matches the subject "Sensor systems", which is only available in the 2023 accreditation.
• F18L3W162 - doesn't exist either, F23L3W162 matches "Quantum computing", which doesn't exist in the 2018 accreditation.
• F18L3W158 - doesn't exist, when swapping F18 with F23 you can find the subject "Modern Computer Architectures"(F23L3W158) which does exist in the 2018 accreditation but is known under the F18L3S158 code. The migration already contains a row that references this subject code.
• F18L3W085 - this code is valid, it exists on the FINKI website and it matches the subject "Introduction to bioinformatics". This subject does have a 2018 accreditation, but there's a problem where inside previous migrations, when creating this subject, the code for it was set to F18W3S085 which looks like it's a typo W3S instead of L3W. The migration already contains a row that references this typo subject code.

The invalid subject codes are not mentioned in any other migration, which makes this safe to remove (assuming the migration never got to run in the first place).

Fix missing openjdk:17 tag

Recently the maintainers of openjdk decided to deprecate the openjdk dockerhub repository and remove the openjdk:17 tag because it was misleading, indicating that you are using the latest version available for 17, which wasn't updated on dockerhub in a few years and was already missing security updates. When trying to pull openjdk:17 it gives an error that it's not found. The last version that was released to dockerhub that matched the openjdk:17 tag is openjdk:17.0.2.

In the deprecation notice the maintainers recommend using a more maintained version of the JDK in production environments, but for stability purposes, to not have any changes in the base image, and to be able to re-use the already cached layers, the 17.0.2 tag is used instead.

Pin PostgreSQL image to version 17

Right now the project is using the latest tag which points to PostgreSQL 18. On fresh installations, when this image is pulled and the docker compose is started, it throws an error that the way the persistent volume is mounted to /data is unsupported in version 18, and instead to mount it differently.

Seeing how there's already existing databases with volumes that are mounted to /data, the version is pinned to 17 which is compatible with this path mapping structure.

Fix first start race condition

When first running the docker compose file, there's a database initialization step which usually takes a few seconds to do. There's a race condition where while the database is being initialized, the common-model application starts up, tries and fails to connect to the database a few times (because it's still initializing), and crashes with an error code.

Added a health check to make sure the database is ready before starting the common_model application, fixing this race condition.