EDTBUC-3258 implement api and persistence

Merge Request

<Description here>

Things to do during Peer Review

Please read all boxes before the Merge Request is approved and merged. Not all boxes must be checked, use good judgement whether to skip a box or not.

• The pipeline is green. This is enforced by GitLab.
• All threads that were created during the review need to be resolved. This is enforced by GitLab
• The MR actually implements what is described in the JIRA-Issue
• The part of acceptance criteria and to-dos covered by this MR are fulfilled.
• The code has been manually inspected by someone who did not implement the feature
• At least one test exists testing the new feature (if applicable)
• If new test files are created, make sure that they are included and actually run in the pipeline
• Documentation is updated as required
  • MkDocs successfully renders the updated documentation
  • Changes to the pipeline, the concrete or the abstract architecture are documented in the relevant diagrams
  • If a new module is created, a corresponding README.md file was created
• The new feature is manually used/tested/observed in any environment (local, pipeline, dev cluster) as required:
  • If changes to tilt files were made, consider starting a tilt session successfully started preceded by make teardown
  • Frontend functionality is tested as required
  • Frontend styling is observed as required
• The automated deployment is updated if required
• If the changes are nightly pipeline sensitive, consider triggering a nightly pipeline