[Backend/Frontend] Rethink how Permissions are handled

[nothingface0]

Currently, the Permission table maps egroups to routes which are allowed to access. This means that only the backend can judge if a user has permission to query a specific API endpoint, and the frontend just displays errors, when protected endpoints are queried.

However, this may be counter-intuitive for users, as they may try to change values that seem like they are modifiable by them (e.g. class for run information, when managing a run), when they're not. Ideally, values that a user is not permitted to change should be, at least, greyed out. As the frontend currently has no knowledge of permissions, this is not possible to be done cleanly.

One approach is to use egroups directly in both frontend and backend code, to disable/enable buttons/actions depending on the egroup, but this has the downside that you will need to change the code each time an egroup must be given/denied access to actions.

Another way to approach this is to create Roles, and who are going used throughout the codebase for permitting/denying actions. A role will be then be granted to each egroup (through the database). This has the disadvantage that it will not be as straightforward to know which actions can be performed by each role in one place (as is the case of the Permission table), and it will add another layer of complexity in the code.