return freshly updated GeoFeature in response to PATCH request [MRXN23-255]

[hotzevzl]

Overview

Return the updated GeoFeature in PATCH responses when users update a feature's name

Feature relevant tickets

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

---

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	Jul 26, 2023 9:59am

[hotzevzl]

@KevSanchez this is basically changing the response payload for PATCH request to edit feature names, but I took a chance to also:

• move this endpoint to the geo-features controller - I don't remember why we decided to put this into the projects controller but I think that it's simpler in the geo-features controller (no need to supply a projectId) and also documentation-wise it's grouped with feature stuff in the OpenAPI/Swagger page
• document that in general we should return created/updated entities in responses to PATCH/PUT requests too
• refactor error handling to use the infamous mapAclDomainToHttpError() strategy
• and of course I've added a small test to check that the response payload is now in JSON:API format (kind of test this, I'm only asserting a couple of things, not really using a JSON:API parser for this)
• i've also removed a test that is now obsolete (as we don't want a projectId from the API consumer anymore, there's no point in asserting that the related project exists, so I've removed that check from the code and done it kind of indirectly by "just" asserting that a feature with the gived id exists and it is not a platform-wide one, which means it must be in a project, and we then check that the user can do stuff in that project)

[KevSanchez]

@hotzevzl Pretty much spot on
I also don't remember exactly the motivation we had for putting the endpoint there in the projects controller. Maybe because editing features wouldn't make sense outside the context of a project (as only custom features are editable, and you would always need the corresponding projectId)?
In any case, this is good to go 👍