API: add participation viewset

[felixrindt]

@jeriox should we keep the users/1/participations endpoint or deprecate it and include user filtering in this one? It's not trivial, as this new ViewSet works on abstract participations and we'd need a few lines to filter for the Local user participations if a user id to filter for is given.

Also, mind that I narrowed the permission check. You now need to be able to view users and the event to see the participations. I'd be fine with only users too, as I find that more important in this case (includes email and stuff). Maybe we should talk about the permission model at some point. For example we could include a reduced view that only shows the VIEW_PUBLIC scoped information like in the web interface (just display name and qualifications, no email).

Todo

• check the endpoint documentation
• More tests

[jeriox]

@jeriox should we keep the users/1/participations endpoint or deprecate it and include user filtering in this one? It's not trivial, as this new ViewSet works on abstract participations and we'd need a few lines to filter for the Local user participations if a user id to filter for is given.

I think we should keep the other one. The usecase is quite different and it feels weird to include users here as it deals with AbstractParticipations

Also, mind that I narrowed the permission check. You now need to be able to view users and the event to see the participations. I'd be fine with only users too, as I find that more important in this case (includes email and stuff). Maybe we should talk about the permission model at some point. For example we could include a reduced view that only shows the VIEW_PUBLIC scoped information like in the web interface (just display name and qualifications, no email).

Both sounds good.
I liked the narrowed-down version for VIEW_PUBLIC

[coveralls]

coverage: 85.162% (+0.01%) from 85.149%
when pulling 190e62b on api-filterable-participations
into 3167a63 on main.