make cost surface data migration idempotent [MRXN23-478]

[hotzevzl]

For context: https://vizzuality.atlassian.net/browse/MRXN23-478

[vercel]

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

Name	Status	Preview	Comments	Updated (UTC)
marxan	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Dec 6, 2023 2:44pm

[hotzevzl]

just an initial draft for now, right after running the data migration in my local dev env and on marxan23:

• I think that using the scenario_id of an existing scenario as id of the corresponding cost surface created by copying over the scenario's current scenarios_pu_cost_data records should not do any harm, and actually can help us guarantee that if we were to re-run the data migration script again (with some further tweaks over the current draft of my changes: we'd need to turn some inserts into upserts), we would not scatter new cost surfaces all over the place (as we would if using gen_random_uuid()) but we'd "just" copy over the scenarios_pu_cost_data costs again
• likewise for creating (or upserting, in a later commit) default cost surfaces using the project's project_id as the cost surface's id

Both these things should maybe handled by using a function to pick a UUIDv4 as a sort of hash (sort of what can be done in Java with this library method: https://stackoverflow.com/a/29059595), but I don't think it's worth the effort (of finding a Python equivalent and using it) over "just" syncing the ids

[hotzevzl]

The other thing I added in this initial draft is to avoid deleting orphaned scenarios - yes, scenarios with cost data in such a bad shape (=likely not even existing, for whatever reason) are going to be useless in practice, but thinking about doing this in staging and production, I think that by keeping around any scenarios with messed-up data, we wouldn't make things worse than they are, and on the other hand we get a chance to inspect and see what's up.

I've seen one such scenario when doing the data migration on m23 and that was a legacy project yadda yadda, plus there were 4 default cost surfaces for which we didn't have min/max data, which was likely because of some mess-up of the project grid (no PUs? some bug in some specific way of creating the grid so that no project_pus were created? I'll need to check more carefully next week).