Execution API

This is a first draft for adding some API endpoints that would allow to automate some tasks.

In particular, this adds two endpoints:

• resolve allows to get all pseudonyms that are relevant for the study for a single subject. As a side effect this can be used to check whether a pseudonym exists. This is equivalent to the resolve UI view.
• attribute export allows to get all attributes for subjects who participate in a study. As a side effect this can be used to get a list of all pseudonyms in a domain. This is equivalent to the attribute export UI view.

While both of these endpoints are related to pseudonyms and execution, I want to establish a general approach for APIs in castellum.

There are still many open questions:

• do we want to allow automation in the first place? What impact does this have on the security concept? Yes, we do. We make it optional though. The security impact is quite small (see next point) but not non-existent because we expose a combination of functionality (access pseudonyms) and authentication method (token header) that was not exposed before.
• In this proposal, the API endpoints provide a subset of the functionality of their UI counterparts. This has the major benefit that very few new concepts are introduced, keeping the overall security architecture simple. However, there might be benefits if some functionality is only available through the API and never exposed to human users. The motivation behind this question is now covered by !1986 (merged)
• In this proposal, the study is used as a context for permissions. This is again very similar to the UI. The downside is that is less generic and can only cover certain use cases. We want to stick with the study context for now
• Where should the API endpoints be in the URL hierarchy? This proposal groups them with their UI equivalents, but they could also be under a new /api/ root.
• Should we use an established framework for APIs? Django-rest-framework comes to mind. However, it is mostly focused on serializing django models, which is not what we need. Still, it would provide nice features such as better error pages (JSON instead of HTML), a well tested authentication implementation, interactive documentation based on OpenAPI, etc. See castellum_scheduler!20 (closed)
• Should parameters be encoded in the path or query string? path
• Authentication: This proposal uses the Authorization header with the token introduced in !1085 (merged). There are certainly other ways to do this. Authentication header is fine