ETL Pipe for download and ingest EEZ [MARXAN-1618]

[aagm]

Overview

This pr adds the makefile pipe to manage EEZ marine boundaries.

Designs

Link to the related design prototypes (if applicable)

Testing instructions

Either make a full db restoration:

1. make clean-slate
2. make start-api
3. make seed-api-init-data
4. make seed-geodb-data

Or run just for Testing the individual pipe:
docker-compose -p marxan-cloud -f ./data/docker-compose-data_management.yml up --no-start --build marxan-seed-data marxan-seed-data && docker-compose -p marxan-cloud -f ./data/docker-compose-data_management.yml run marxan-seed-data make seed-eez

Checklist before submitting

• Meaningful commits and code rebased on develop.
• If this PR adds feature that should be tested for regressions when
  deploying to staging/production, please add brief testing instructions
  to the deploy checklist (docs/deployment-checklist.md)
• Update CHANGELOG file

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Updated
marxan	✅ Ready (Inspect)	Visit Preview	Jun 1, 2022 at 2:34PM (UTC)
marxan-storybook	✅ Ready (Inspect)	Visit Preview	Jun 1, 2022 at 2:34PM (UTC)

[hotzevzl]

sorry I had missed parts of this PR while I reviewed it - probably my tab wasn't refreshed when you pushed later changes... this bit, I recommend to handle it differently, without hardcoding cookie and most of the form data such as name, org, email, country, user_category, purpose_category

[hotzevzl]

how to do this... my first thought would be to move the whole curl command to a simple shell script that is committed to the repo with placeholders, and needs to be copied to a specific file (that should be added to .gitignore, similarly to env.default vs .env), mounted in the eez ingestion container, and executed in the eez Makefile

[hotzevzl]

@aagm for the failing tests (https://github.com/Vizzuality/marxan-cloud/runs/6691428000?check_suite_focus=true for example), IIRC each migration file is wrapped in a transaction so we may need two migrations in order for the enum to be fully committed by the time it's then used. I don't think (again IIRC, and IIRC the docs are thin on this - I'd need to read the source code...) that using two distinct queryRunner.query() steps in the same migration will be enough.

Or avoiding touching that enum altogether and going the separate table route 😜