Review CfP data model

[russss]

Given the increasing demand for more granular proposal types (#1514, #1515, #1601), we should review how we model these to see if we should make any changes before 2026.

The proposal type governs several things:

• Which fields are required/allowed
• Which review process is used (for non-attendee content)
• Which scheduling process is used (manual/slotmachine)
• Where the proposal is allowed to be scheduled, both automatically and manually (Scheduling time constraints should be specified in a less baffling way #1150)
• How the proposal is displayed in the schedule

We currently use SQLAlchemy's single-table inheritance to differentiate between proposal types. This causes some occasional annoyances - maybe it would be better done another way.

We likely also want to consider #1789 at the same time. This may move the schedulable items to a different class (which I'm provisionally calling "occurrence").

[russss]

One possible approach - which I'm not especially wedded to - is to flatten the whole thing out, and divide it up this way:

• Basic proposal type: anonymous review, manual review, or attendee content.
• Anonymous review category: talk or workshop
• Subtype for display: talk, workshop, film, comedy, live music, DJ set, gathering, pissup.

The subtype could be a free text field where specific defined values can enable certain fields (e.g. music gets a genre, film gets a classification, pissup gets a preferred beverage).

Perhaps these custom fields which aren't otherwise used in the CfP system could be stuffed in a JSON column or a separate key/value table rather than an ever-wider table, which would then make it easier to customise them.

[SamLR]

The proposal type governs several things:

* Which fields are required/allowed

* Which review process is used (for non-attendee content)

* How the proposal is displayed in the schedule

This list should probably include "scheduling process (manual/via slot machine, which venues/time slots)

[Jonty]

I was going to suggest type specific columns being shoved into a JSON column too, but I am a little worried about that biting us later.

Whatever we do, we need to be able to convert proposals from one type to another.

[marksteward]

There are two annoyances AIUI:

• The sqla identity mapper doesn't really support changing polymorphic type. As a result, you get a warning in the logs and it's not easy to make code that updates columns in advance of the switchover. This isn't really a major issue as usually we commit just before the end of a request and the session gets closed, but we don't currently call this out.
• A consequence of this is that there are columns that are subtly different between types but are inherited (equipment_required) or should really be only exposed on subclasses (length). These should really be more tied to the type, and I feel like they belong in different tables. The lack of explicit migration means we end up with 1de92a0.

Switching to e.g. a parent table that holds the really basic information along with a related, per-type model might help with some of this, but as Jonty notes we won't be able to get rid of the requirement for the convert endpoint. Some of columns are close matches and share information, and we may even want to request extra information in order to convert between some types. Also what happens to historic changes?