Update API to use events and task states + fixes to backend refactor

[spwoodcock]

What type of PR is this? (check all applicable)

• 🍕 Feature
• 🐛 Bug Fix
• 📝 Documentation
• 🧑‍💻 Refactor
• ✅ Test
• 🤖 Build or CI
• ❓ Other (please specify)

Related Issue

Fixes #1610

Describe this PR

Redesign of how the task locking works:

• Events are called via the API to trigger certain states on the tasks.
• We have a TaskEvent enum listing all the possible events.
• Then a MappingStatus enum to list all the possible statuses for mapping currently.
• The backend is mostly implemented, but I just need to update the naming of a few things, and pass in a JSON to the new event endpoint to task_id, user_id, event.
• The frontend however is a little bodged now after all these changes 😅 I really ran out of time to dive into the frontend code properly, so just did what I could for now. I would really love your help getting this to work @NSUWAL123 🙏

This includes a pretty major migration to the task_history table, changing the fields and table name to task_events.
The indexes are also all rebuilt.

Also includes fixes to various endpoints and frontend usage of endpoints after refactor in #1834

Review Guide

Notes for the reviewer. How to test this change?

Checklist before requesting a review

• 📖 Read the FMTM Contributing Guide: https://github.com/hotosm/fmtm/blob/main/CONTRIBUTING.md
• 📖 Read the HOT Code of Conduct: https://docs.hotosm.org/code-of-conduct
• 👷‍♀️ Create small PRs. In most cases, this will be possible.
• ✅ Provide tests for your changes.
• 📝 Use descriptive commit messages.
• 📗 Update any related documentation and include any relevant screenshots.

[optional] What gif best describes this PR or how it makes you feel?

[NSUWAL123]

Would you merge this PR to dev first or should I make a branch from your branch?

[NSUWAL123]

@spwoodcock One thing you missed in the previous PR I guess to update the fmtm-db --> build --> context version update from 3.4 to 3.5. Realized just now when trying to build.

[spwoodcock]

Would you merge this PR to dev first or should I make a branch from your branch?

If you could branch from branch for today, I'll also continue to tweak the backend today & hopefully get that part done.

Last thing I need to fix is updating the task and entity status properly from the frontend.

For better clarity over what has changed, I think this code from enums.py helps to illustrate it:

class TaskEvent(StrEnum, Enum):
    """Task events via API.

    `MAP` -- Set to *locked for mapping*, i.e. mapping in progress.
    `FINISH` -- Set to *unlocked to validate*, i.e. is mapped.
    `FINISH` -- Request recent task ready to be validate.
    `GOOD` -- Set the state to *unlocked done*.
    `BAD` -- Set the state *unlocked to map* again, to be mapped once again.
    `SPLIT` -- Set the state *unlocked done* then generate additional
        subdivided task areas.
    `MERGE` -- Set the state *unlocked done* then generate additional
        merged task area.
    `ASSIGN` -- For a requester user to assign a task to another user.
        Set the state *locked for mapping* passing in the required user id.
        Also notify the user they should map the area.
    `COMMENT` -- Keep the state the same, but simply add a comment.
    """

    MAP = "MAP"
    FINISH = "FINISH"
    VALIDATE = "VALIDATE"
    GOOD = "GOOD"
    BAD = "BAD"
    SPLIT = "SPLIT"
    MERGE = "MERGE"
    ASSIGN = "ASSIGN"
    COMMENT = "COMMENT"


class MappingState(StrEnum, Enum):
    """State options for tasks in FMTM.

    NOTE We no longer have states invalidated / bad, and instead rely on the
    EntityState.MARKED_BAD buildings to display red on the map.
    """

    UNLOCKED_TO_MAP = "UNLOCKED_TO_MAP"
    LOCKED_FOR_MAPPING = "LOCKED_FOR_MAPPING"
    UNLOCKED_TO_VALIDATE = "UNLOCKED_TO_VALIDATE"
    LOCKED_FOR_VALIDATION = "LOCKED_FOR_VALIDATION"
    UNLOCKED_DONE = "UNLOCKED_DONE"


class EntityState(IntEnum, Enum):
    """State options for Entities in ODK.

    NOTE here we started with int enums and it's hard to migrate.
    NOTE we will continue to use int values in the form.
    NOTE we keep BAD=6 for legacy reasons too.
    """

    READY = 0
    OPEN_IN_ODK = 1
    SURVEY_SUBMITTED = 2
    MARKED_BAD = 6

So with these updates the whole idea is to post TaskEvent to the API, which creates an entry in the events table.

The MappingStatus will be automatically set from that.

We can also post the EntityState to update it, but I need to work on that part a bit more 👍

[NSUWAL123]

Sure, I'll make a branch and continue. I'll look through it and make the frontend fixes.

[spwoodcock]

Fixed all the remaining issues.

Going to merge this, but the Playwright tests are still a bit broken, so this can't deploy to dev.

Could you take a look into the tests please @NSUWAL123 ? 🙏