The following attribute names were marked as deprecated in the schedule
request and have been replaced by their new names:

  dstart → first_date
  until → last_date
  tstart → start_time
  tend → end_time
  byweekday → by_weekday

Apart from that this commit fixes a few documentation errors.

This adds extensive API documentation based on the official API
documentation [1] and conflict resolution [2] documents.

Where possible field documentation was added to models or serializers,
so that other code like auto-generated forms can also profit from these
changes (hence the migration part of this commit).

The changes introduce two new API endpoints.

`/api/v1/schema/` exposes the API schema as an OpenAPI 3.0.3 document.
The standard format is yaml but can be switched to JSON by appending the
`?format=json` query parameter.

`/api/v1/schema/swagger-ui/` renders a visual representation of the
OpenAPI 3 specification with support for testing the individual API
endpoints including authentication.

[1]
https://gitlab.servus.at/aura/meta/-/blob/ec3c753d34ccb0269969808ac7dc28fff2ff1648/docs/development/api-definition.md
[2]
https://gitlab.servus.at/aura/meta/-/blob/ec3c753d34ccb0269969808ac7dc28fff2ff1648/docs/development/conflict-resolution.md

Schedule dry-runs returned a 201 response before, because the only check
for a 201 return code was, that the payload must not contain the
"projected" keyword.

As dry-runs don’t create any data 201 is not an appropriate status code.

The retrieve and update actions can be removed because the get_queryset
method already ensures that the user has only access to their own user
object (or all user objects in case of superusers).

Sending 401 responses for unauthorized requests may also be considered
leaky, because it exposes that these objects exist instead of returning
a 404 that simply states that no object with that primary key can be
found.

Most of the queryset filtering for subroutes formerly implemented
through custom get_queryset methods can happen semi-automated through a
mixin, making the behaviour re-usable and allowing us strip a lot of
additional logic for retrieving objects.

The use of the viewset get_object method also allows us to implement
object access with permission classes in the future, and should make a
whole lot of other code obselete.

This change is primarily motivated by the fact that documentation of the
API will become a lot easier if the subroutes don’t impose arbitrary
restrictions on the specific subpath under which an operation is
allowed. For instance updating a schedule should be possible through
either /schedules/<pk>/ or
/shows/<show_pk>/schedules/<schedule_pk>/ as long as all the necessary
data is present in the request body.

The show retrieve method allowed shows to be identified through the slug
or the id. This is handy, but was restricted to the retrieve and did not
apply to the update nor delete methods. The proper way to implement this
kind of behaviour is through overriding get_object so that route
identifiers are handled consistently.

This adds extensive API documentation based on the official API
documentation [1] and conflict resolution [2] documents.

Where possible field documentation was added to models or serializers,
so that other code like auto-generated forms can also profit from these
changes (hence the migration part of this commit).

The changes introduce two new API endpoints.

`/api/v1/schema/` exposes the API schema as an OpenAPI 3.0.3 document.
The standard format is yaml but can be switched to JSON by appending the
`?format=json` query parameter.

`/api/v1/schema/swagger-ui/` renders a visual representation of the
OpenAPI 3 specification with support for testing the individual API
endpoints including authentication.

[1]
https://gitlab.servus.at/aura/meta/-/blob/ec3c753d34ccb0269969808ac7dc28fff2ff1648/docs/development/api-definition.md
[2]
https://gitlab.servus.at/aura/meta/-/blob/ec3c753d34ccb0269969808ac7dc28fff2ff1648/docs/development/conflict-resolution.md

Schedule dry-runs returned a 201 response before, because the only check
for a 201 return code was, that the payload must not contain the
"projected" keyword.

As dry-runs don’t create any data 201 is not an appropriate status code.

The retrieve and update actions can be removed because the get_queryset
method already ensures that the user has only access to their own user
object (or all user objects in case of superusers).

Sending 401 responses for unauthorized requests may also be considered
leaky, because it exposes that these objects exist instead of returning
a 404 that simply states that no object with that primary key can be
found.

Most of the queryset filtering for subroutes formerly implemented
through custom get_queryset methods can happen semi-automated through a
mixin, making the behaviour re-usable and allowing us strip a lot of
additional logic for retrieving objects.

The use of the viewset get_object method also allows us to implement
object access with permission classes in the future, and should make a
whole lot of other code obselete.

This change is primarily motivated by the fact that documentation of the
API will become a lot easier if the subroutes don’t impose arbitrary
restrictions on the specific subpath under which an operation is
allowed. For instance updating a schedule should be possible through
either /schedules/<pk>/ or
/shows/<show_pk>/schedules/<schedule_pk>/ as long as all the necessary
data is present in the request body.

The show retrieve method allowed shows to be identified through the slug
or the id. This is handy, but was restricted to the retrieve and did not
apply to the update nor delete methods. The proper way to implement this
kind of behaviour is through overriding get_object so that route
identifiers are handled consistently.

This change re-implements all existing collection filters for the
APINoteViewSet with a FilterSet. No breaking changes are expected.

* TODOs are no longer part of the method description
* normalized queryset handling
* consistent formatting of method descriptions.

If notes are created through subroutes some of the data necessary to
create a note is already available through the route data and doesn’t
need to be passed as part of the request body anymore.

Notes will only be created if called through a timeslot subroute. The
typo prohibited the note creation, because timeslot_pk was always None
and caused the view to error early.

APICategoryViewSet, APITypeViewSet, APITopicViewSet,
APIMusicFocusViewSet, APIFundingCategoryViewSet, APILanguageViewSet, and
APIHostViewSet all used the same base class implementing get_queryset
for filtering by their active state. This is now handled by a generic
FilterSet.

* normalized queryset handling
* consistent formatting of method descriptions.

There is no point in advertising the methods by inheriting from
the default CRUD viewset, if we don’t actually intend to implement them.

This change re-implements all existing collection filters for the
APITimeSlotViewSet with a FilterSet. No breaking changes are expected,
though there are some changes in semantics:

* The start and end query parameters no longer need to be specified
  together. If users only want to modify the start or end date they
  can now do that.
  If start is specified and end is not, end will be start + 60 days.
* If end was not set it would default to start + 60 days at 00:00.
  This is now fixed and end will be start + 60 days at 23:59:59.
* end now uses time.max, which selects the latest possible time on
  the specified date.
* The surrounding-filter now accepts a datetime value and will be set
  to the current time if only the query parameter but no value
  has been set.
* All filters are now applied in series. This wasn’t the case for
  every filter, e.g. the surrounding-filter would return early.

This change re-implements all existing collection filters for the
APIShowViewSet with a FilterSet. No breaking changes are expected,
though there are some changes in semantics:

* The owner, host, musicfocus, language, category, and topic
  filters now accept multiple values (i.e. ?category=2,3)
* The owner, host, musicfocus, language, category, topic, and type
  filter values are now validated and may be rejected as invalid if
  the referenced object does not exist.

- Reorder the code inside the methods to fail fast on autorization,
- Replace `int_or_none` with a more generic solution, and move to utils,
- Add `get_values` and move `pk_and_slug` as `get_pk_and_slug` into utils,
- Replace calls to static methos in models local queries,
- Return meaningful status code while creating and updating resources,
- Return `409` when creating or updating a schedule produces a conflict.

- update the model
- migrate the model
- update the serializer
- update the views

- updated the fixture
- updated the serializer
- updated some views

- Introduce `ActiveInactiveMixin` with the `get_queryset` method and `permission_classes`
- Use `ActiveInactiveMixin` for `Category`, `FundingCategory`, `Language`, `MusicFocus`, `Topic`, `Type` and `Host`