Cross-tenant assessment access

[jalvord1]

Description & motivation

Link to Jira ticket with longer description

Breaking changes introduced by this PR:

This feature by default will change nothing, so it's not inherently breaking. However, this feature has major impacts when turned on and must be carefully configured to ensure proper data access for historical assessment records.

PR Merge Priority:

• Low

Changes to existing files:

• fct_student_assessment : When configured, student assessment records will be 'duplicated' across all tenants where a student (based on student_unique_id) has a current enrollment.
• dim_assessment : When this feature is configured, assessment records will be 'duplicated' across any tenants where there are student records and the metadata for that assessment/tenant/year combo does not exist.
• eventually objective assessment models as well

New files created:

• bld_ef3__student_assessment_cross_tenant : This model is where we determine which tenants students are currently enrolled in, and then associate an original k_student_assessment value to all of those tenants, regardless of the tenant it was originally associated to. This is basically a linking model, and then all downstream models can use this information as-needed.

Tests and QC done:

• Currently in testing for accuracy, performance, etc

edu_wh PR Review Checklist:

Make sure the following have been completed before approving this PR:

• Description of changes has been added to Unreleased section of CHANGELOG.md. Add under ## New Features for features, etc.
• Code has been tested/checked for Databricks and Snowflake compatibility - EA engineers see Databricks checklist here
• Reviewer confirms the grain of all tables are unchanged, OR any changes are expected, communicated, and this PR is flagged as a breaking change (not for patch release)
• If a new configuration xwalk was added:
  • The code is written such that the xwalk is optional (preferred), and this behavior was tested, OR
  • The code is written such that the xwalk is required, and the required xwalk is added to edu_project_template, and this PR is flagged as breaking change (not for patch release)
  • A description for the new xwalk has been added to EDU documentation site here
• If a new configuration variable was added:
  • The code is written such that the variable is optional (preferred), and this behavior was tested, OR
  • The code is written such that the variable is required, and a default value was added to edu_project_template, and this PR is flagged as breaking change (not for patch release)
  • A description for the new variable has been added to EDU documentation site here

Future ToDos & Questions:

• This feature assumes that student_unique_id is globally unique. That might not be true for some multi-tenant implementations, but not currently so we are not making the ID type configurable at this time.

[rlittle08]

I think this is a very smart design, and easy to read, which is surprising given how confusing of a problem it is. I have a lot of small ideas but wouldn't change the overall approach at all