Get rid of propertyDefinitionModel and eventDefinitionModel

[mariusandra]

Bug description

There are many parts of the app that still rely on all propertyDefinitions to be loaded into propertyDefinitionModel before they start to work properly.

Unfortunately the property flattener plugin makes it possible to easily have 100k+ properties, rendering parts of the app flakey for the first 10sec or even (much, much) longer, while all the properties load:

Some recent issues where this has come up:

• Numeric properties disabled #8213
• Allow trends to do maths with page performance #8255

We have a few heavy users who could even load hundreds of megabytes of properties into memory.

Expected behavior

Various filters and other widgets still rely on propertyDefinitionsModel and eventDefinitionsModel to be populated with data that's always there.

We need to remove these models, and introduce paginated data loading where needed.

[pauldambra]

I don't think that #8255 is the same issue

Although I don't want that to take away from my agreement that the "maybe you can query for this thing" behaviour is confusing :)

[mariusandra]

Here are the various ways propertyDefinitionsModel is used. Unfortunately there's no quick "one size fits all" solution, so we're going to have to uproot it one by one.

• In the Properties table, we check for the type of the property and display it next to the actual property like string. We display the type in the database even if the actual displayed value has a different type:
  

• In the Events table the list of property names is used to configure table
  

• The OperatorValueSelect component uses the property type from the model to limit the comparisons you can do with a property
  

• The PropertyValue and SelectGradientOverflow components use formatForDisplay to format the list of values depending on the type of the property. This function currently just provides custom formatting for datetimes. Since we don't autocomplete them anymore, perhaps this can be removed. (Screenshot taken via a bug: set it to a string property, then type $time and press enter, you'll get the old "equals" filter with a list)
  

• But even if we don't use it in the list, we use it in the PropertyFilterButton pill:
  

• The MathSelector in ActionFilterRow toggles the option to sum/average/etc any numerical property, if we have any numerical properties, plus presents a list of numerical properties to choose from: Replace math property selector with taxonomic selector #8389
  

• The Properties stats page depends on this. Doesn't exist anymore.
  

Depending on the usage, we need to either move to a universal paginated list, change to an autocomplete filter, or making bespoke queries to fetch just one property (e.g. loading a page with a filter --> find out what type it is).

[mariusandra]

The eventDefinitionModel is used:

• In the "Event stats" page no longer a page we have
• When using the taxonomic filter group TaxonomicFilterGroupType.CustomEvents, which is only done under paths. feat(data-management): add custom events list #11463
• In ActionStep when asking to select the name of the custom event Taxonomic popup component #8399
• In EventTable above the property filter to show the event name filter Taxonomic popup component #8399
• When choosing an event entity type for a cohort: Refactor old cohort event selector #8416
  
• eventNames is also used in some places. Must investigate.

[pauldambra]

excellent analysis 🙌

(Screenshot taken via a bug: set it to a string property, then type $time and press enter, you'll get the old "equals" filter with a list)

That component is going to make me go bald even faster! e.g. #7970

[pauldambra]

I hope you've done a victory lap around the house @mariusandra