Consider adding foreign key relationships between activity types, directives, and spans

• activity_directive table should be foreign key constrained to the activity_type table to enforce that activity directives have valid activity types
• span table should be foreign key constrained to activity_directive table to enforce that any given span is a valid activity directive (unless the span is a child activity in which case the foreign key will be null)
  • A span associated with an activity directive already has a weak relationship to the activity_directive table via a property in the jsonb attributes column called directiveId. This relationship should be codified in the database with foreign key constraints to enable proper joins and elucidate the relationship.

Some considerations per @mattdailis:

1. Performance. Creating a foreign key relationship requires an index which could slow things down if you are writing since index updating can be expensive.
2. We should not be deleting spans when we delete an associated activity directive since spans can be viewed in historic simulation data. Does adding a foreign key require deleting a span when deleting the associated activity directive?

Transferred Internal Tickets:

1. https://jira.jpl.nasa.gov/browse/AERIE-1839
2. https://jira.jpl.nasa.gov/browse/AERIE-1840
3. https://jira.jpl.nasa.gov/browse/AERIE-1841

No files, tests, or entry points are named. Start by locating the schema definitions for the activity_type, activity_directive, and span tables, then inspect how directiveId is stored in span.attributes. Done means the relationships are enforced, child-activity spans can retain a null relationship, and deleting an activity directive does not delete historical spans.