Use HTTP status codes consistently

[Masclins]

Description of the current situation Currently, the api returns to the frontend a game state where there is a :status. The current status is only used by the frontend to decide what to show, but can be known using only completely public information.

Also, at configurations/configuration.yml and the files that use that we are treating the same way the messages used to describe the statuses and errors.

And (probably the most notorious thing) we are always returning code 200, even when we return an error message.

Description of what I'd like A clear documentation on how we use HTTP statuses and create a wrapper function that assigns it with the appropiate code and message. An important part would be returning code 4xx when we are also returning an error message.

That would imply modifying the configurations/configuration.yml so it intuitively shows which are error messages and which aren't

Describe alternatives you've considered I've thought about simply dividing the configuration.yml file in statuses and errors, but that doesn't makes thinks clearer, since we are always returning a status code 200.

Also, I created this Issue suggesting to remove the :status from backend, but apparently that wouldn't be compliant with HTTP status codes.

Notes I labeled it as minor, but if we begin to use this status for more things (probably for weird or lazy reasons) it'll be more difficult to change.

Edited after the comment from @kenan-rhoton

[kenan-rhoton]

I'm not sure I agree on this... Status Codes are part of the HTTP standard, and we should whenever possibly comply with it when using HTTP (as we currently do for backend-frontend communication).

If as you say, it can be derived from all other information, then we could just create a assign-status wrapper function that transforms the API response and assigns de appropriate status.

Yes, HTTP Status Codes are stupid, but we are using HTTP...

[Masclins]

Migrated to https://github.com/doner-kebard/card-game-backend