[MRXN23-531]: invalidates cost-surface fetch a second later of creation

[andresgnlez]

Substitute this line for a meaningful title for your changes

Overview

This PR delays the query invalidation of cost surfaces up to one second so it avoids falling in limbo when the API processes the cost surface between the POST callback and the first /status polling. If the API takes more than that second into processing the cost-surface, the /status will in charge of telling the application when the query invalidation should occur.

For future reference:

Designs

Link to the related design prototypes (if applicable)

Testing instructions

Please explain how to test the PR: ID of a dataset, steps to reach the feature, etc.

Feature relevant tickets

https://vizzuality.atlassian.net/browse/MRXN23-531

---

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	Comments	Updated (UTC)
marxan	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Feb 20, 2024 2:13pm

[hotzevzl]

@andresgnlez thanks for all your patient explanations off-band today.

All looks good to me, and I can reliably get cost surfaces to display once the async upload job has completed, with this change applied.

What puzzles me a bit is that:

• on marxan23.vercel.app (so, without this change applied until now), I can't trigger the behaviour whereby a cost surface is not added to the sidebar and legend once its async upload job is done, even with super-simple grids where the limbo situation will very often happen - basically there the undesirable behaviour doesn't seem to happen already 🤷🏼
• using the same develop branch as marxan23.vercel.app but running it locally, and with the marxan23 API as backend, I cannot trigger the undesirable behaviour either 🤷🏼
• same as above (develop frontend running locally) but using api.marxanplanning.org as backend, I can consistently trigger the undesirable behaviour

So I guess there's some PEBKAC somewhere on my end 🤷🏼 but nevertheless, since local app with this PR's branch and api.marxanplanning.org as backend always avoids the undesirable behaviour, I'd say that we can consider this fixed. Why on earth a different backend would make any difference is 🤯 to me, but I also think that trying to understand this at this stage is not a battle worth fighting. In case this issue raises its head again somehow, then hopefully we'll remember what I observed while checking this PR in case that could help to shed any light. But hopefully we won't need any of this once merging this PR - which I'm going to do in a few moments.

thanks @andresgnlez!