Refactor DB setup Part 1

[RichDom2185]

Part of #14.

Part of #54.

Part of #81.

This design would remove coupling from the actual DB layer (as well as between models and its associations), as none of the SQL statements would actually be executed (but still allows to check for correctness of behaviour, especially when checking against potentially nullable/non-nullable values).

[RichDom2185]

After spending some time thinking about it, I figured this might be a good way to separate out the logic:

• The general idea is that the actual DB transaction is contained within the model itself as a private method, thus controllers cannot mistakenly call it directly
• The model will then expose a function that controllers can call to update the DB.

This design would also mean it would make it easier to make operations that involve multiple models atomic, simply by calling the individual structs' methods. An example of this atomicity issue was introduced in #102, where the usergroups data are dependent on the users themselves having been created prior to the operation. We can simply expose an create/update function from the UserGroups model that calls the methods from the individual structs (since they belong to the same package).

[github-actions[bot]]

coverage: 49.653% (-0.08%) from 49.731% when pulling b74bbfcd828a24cc3330b5f5276c02a128adf76a on refactor-db-1 into ec1472174de3395394d7edd564ac72acac9f66cb on main.