refactor(db): add extraInitContainers hooks and writable migration

[inaki321]

What kind of change does this PR introduce?

refactor

What is the current behavior?

Currently, the database initialization process is strictly tied to static files provided via ConfigMaps. Users cannot dynamically fetch migration or seed data (e.g., from AWS S3, Google Cloud Storage, or external APIs) because the custom-migrations volume is read-only.

Additionally, there are no lifecycle hooks to perform pre-initialization setup or post-initialization validation.

What is the new behavior?

This PR introduces Life Cycle Hooks and a Writable Workspace for the database initialization process:

Pre/Post Init Hooks: Added extraInitContainersBefore and extraInitContainersAfter to the DB StatefulSet. This allows users to inject sidecars (like aws-cli or rclone) to fetch data or run validation scripts.

Shared Writable Volume: Introduced a new emptyDir volume (custom-fetch-scripts) mounted at /custom-fetch.

Dynamic Migration Loading: Updated the init-db script to automatically detect and copy any SQL files found in the /custom-fetch directory into the final /initdb.d/migrations/ path.

Additional context (TEST)

WITHOUT stays the same as before
Example:

deployment: 
  db:
    extraInitContainersBefore: []
    extraInitContainersAfter: []
     or 
    #extraInitContainersBefore: []
    #extraInitContainersAfter: []

WITH new params, adds the new init container:
Example:

deployment: 
  db:
    extraInitContainersBefore:
      - name: pre-seed-generator
        image: busybox
        command: ["/bin/sh", "-c"]
        args:
          - |
            echo "CREATE TABLE IF NOT EXISTS hello_world (id serial primary key, msg text);" > /custom-fetch/01-test.sql
            echo "INSERT INTO hello_world (msg) VALUES ('Hook worked!');" >> /custom-fetch/01-test.sql
            echo "Pre-seed file created in shared volume."
        volumeMounts:
          - name: custom-fetch-scripts
            mountPath: /custom-fetch

    extraInitContainersAfter:
      - name: post-init-validator
        image: busybox
        command: ["/bin/sh", "-c"]
        args:
          - |
            echo "Database initialization sequence finished."
            echo "Sending deployment notification to Slack/Webhook..."
            # curl -X POST https://hooks.slack.com/...

[luizfelmach]

Hi @inaki321. Thanks!

Some thoughts I had about it.
It seems like a workaround for something that could potentially be handled through a ConfigMap (I agree that this might not be the most ideal approach). Personally, I’m more inclined to keep using the ConfigMap for now rather than performing a fetch to retrieve the files.

If you think it might be beneficial, we could open an issue to discuss whether adding this behavior to the Helm chart would make sense in the future.