feat: Build assets for vanilla metabase image

[adskyiproger]

Note

Currently, we do not run e2e tests as a check on opencrvs-countryconfig-repo PRs. Please ensure your PR doesn't break any e2e tests.

One method for doing this is to open a PR with these changes to opencrvs-farajaland as well, and see if the PR check passes there.

Description

This PR aims to address issue opencrvs/opencrvs-core#11146

Preconditions:

• We would like to use default metabase image
• Helm doesn't support large files like metabase.init.db.sql which is used for metabase configuration

Idea:

1. Build a small image that just contains SQL/scripts.
2. Use that image in an initContainer.
3. The initContainer copies those files into a shared volume.
4. The Metabase container mounts the same volume and uses the files.

How it works?

• Large files live in a container image (registry), same repository as countryconfig with suffix -assets
• Official metabase/metabase image is used for the main container.
• Helm remains simple

See related PR with infrastructure changes: opencrvs/infrastructure#195

!!! This PR contains tricky code !!!

This is not best practice to create 2 docker images within the same repository, from different base images.

Image build produce 2 artifacts, e/g:

• ocrvs-countryconfig:e359075: country config
• ocrvs-countryconfig:e359075-assets: Metabase assets

In general best practice says we need to setup 2 repositories, but DockerHub has support only for one no-cost private repository.

Checklist

• I have linked the correct Github issue under "Development"
• I have tested the changes locally, and written appropriate tests
• I have tested beyond the happy path (e.g. edge cases, failure paths)
• I have updated the changelog with this change (if applicable)
• I have updated the GitHub issue status accordingly

[github-actions]

Oops! Looks like you forgot to update the changelog. When updating CHANGELOG.md, please consider the following:

• Changelog is read by country implementors who might not always be familiar with all technical details of OpenCRVS. Keep language high-level, user friendly and avoid technical references to internals.
• Answer "What's new?", "Why was the change made?" and "Why should I care?" for each change.
• If it's a breaking change, include a migration guide answering "What do I need to do to upgrade?".