Improve coverage of OpenAPI schemas

[brojd]

Now that we have a simple way of generating TS type definitions based on OpenAPI schemas, in order to proceed with making use of it and improving type-safety of the frontend, we should try to increase coverage of OpenAPI schemas on the backend as much as we can.

This task is for assessing if current solution for OpenAPI schemas generation on the backend is still the way to go. If the answer is 'yes', then we should try to fix it so that OpenAPI schemas reflect real API contract. If the answer is 'no', let's explore alternatives.

Side note is that frontend has the ability to add custom properties to autogenerated types if needed, however, ideally we should aim to reduce usage of it. It should be used just as a temporary workaround to not block frontend progress rather than a target solution.

[vadimkerr]

Based on the changes in #3629, I think drf-spectacular is still the best option to generate the OpenAPI schema. It has some learning curve to it and adds some maintenance overhead, but still it's pretty good at inferring types automatically for the most part and works reasonably well with our codebase.

Further backend-related action items:

• https://github.com/grafana/oncall-private/issues/2456
• https://github.com/grafana/oncall-private/issues/2457