refactor: cleanup API and add pydantic models for typing

[b-rowan]

General API and auth fixes, as well as pydantic models for most of the endpoints (except for download, because I moved it around in #47, and it cant use the models anyway). Moves things around to make it more clear what parts of the code do what.

[tsagadar]

Why not splitting the code by operation? E.g. that we rather have a devices/delete.py that contains request, response and logic of the delete request? In the new org, one has to look at three files to understand a single request.

[b-rowan]

Why not splitting the code by operation? E.g. that we rather have a devices/delete.py that contains request, response and logic of the delete request? In the new org, one has to look at three files to understand a single request.

I opted to mirror the way that FastAPI structures its directories. This is fine too, if we prefer that I can swap to that.

[tsagadar]

Why not splitting the code by operation? E.g. that we rather have a devices/delete.py that contains request, response and logic of the delete request? In the new org, one has to look at three files to understand a single request.

I opted to mirror the way that FastAPI structures its directories. This is fine too, if we prefer that I can swap to that.

If this new way is documented somewhere then that is ok as well. On a quick search I found these practices which are close to the new structure: https://github.com/zhanymkanov/fastapi-best-practices?tab=readme-ov-file#project-structure

This would be another approach: https://stackoverflow.com/a/64987404

[tsagadar]

Huge rework - I like where this is going. One small thing left for this PR with the POST/PUT.

An open issue for another PR is then to remove the tenant and have the /ddi prefix.

Lastly: is the new file structure based on any documented approach how to organize such projects? If yes, reference it in the README.md. This could reduce discussions / uncertainties where to put what.