* migration for person/group property support in property definitions table
* Use database default
* Validate correct constraint
* Ingest person and group type property definitions
* Exclude person/group type definitions from API
* Update property definitions test
* Ignore $groups
* Add new unique index which accounts for type and group_type_index
* Run new code only in test
* Ignore errors from propertyDefinitionsManager which may occur due to migrations
* Update constraint name
* Update test describe
* ON CONFLICT based on the index expression
* Add a -- not-null-ignore
* Combine migrations
* Remove some test code temporarily
* fixup latest_migrations
* Add command for materializing columns
Expecting this to get used in both dev as well as when improving
upstream installations
* No clashes in tests
* Solve for feedback
* Comments for clarity
* Hotfix: Use materialized columns on cloud
This was broken since default_kind was different on Distributed tables
on cloud
* Improve __init__.py
* Make reverting DEFAULT column async, only ON CLUSTER for events table
* Avoid naming collisions when materializing columns
1. Prefix person properties differently. Mixing them up can break
ambigious column issues
2. When name already exists, suffix with random junk :)
* Implement analyze.py
* Add `suggested_columns_to_materialize`
* Add code to backfill a materialized column
* Add tests for backfilling data
* Cleanup
* Add tests for analyze
* WIP: Crontab for materializing columns
* Nooped task for materializing properties
* Use mutations_sync=0 for column tests
* Add comment
