Authorizer: Update homeroom method to be built from student methods

[kevinrobinson]

Who is this PR for?

students, families, educators

What problem does this PR fix?

This fixes an authorization gap between the methods answering "what homerooms can an educator access" and "what students can an educator access"? For users with access to the homeroom page, this can result in two problems. This has come up at the start of this school year for this first time.

First, the homeroom dropdown shows homerooms where they wouldn't have access to view full profiles for any students.

Second, if using the dropdown to visit other homeroom pages, those pages would show name and other information about those students, but the student authorization check would prevent access to the profile or to the student photo. This does result in authenticated educators being able to view enrollment information, and other information including disability status.

Student-level authorization rules blocked photos from loading, or from full profiles from being accessed. Monitoring on this is how we came to learn about the problem (there have been no reports from educators).

The core difference in semantics between the previous homeroom-level authorization method and student-level authorization is that the previous homeroom method would include homerooms at the same grade level in the same school as the educator's homeroom, if it was assigned. This would also result in older homerooms (with no students listed) being incorrectly included in the list.

What does this PR do?

• Move previous homeroom authorization method from Educator to Authorizer, rename it as deprecated and require callers to pass acknowledge_deprecated:true.
• Audit that there are no calls to previous authorization method outside of tests.
• Add new method, built off of student-level authorization.
• Add new tests to verify expected behavior of new method, including that it no longer includes homerooms at the same grade level and school, and that it excludes homerooms with no active students. Add parity tests showing the behavior is the same as the previous method, and describe all differences in test cases. Add option to describe differences with "no students" homerooms in test cases.
• Fix old spec setup bugs where grade: 'K' was set on homeroom directly, instead of KF on student model. Add explicit validation of grade on Homeroom model as well.
• Add PerfTest to test for performances regressions, verify no issues across districts.
• Run manual data quality checks in production.
• Add more test cases verifying current behavior to HomeroomsController

This does not cut over the behavior in HomeroomsController, so nothing should change by shipping this, and I'll do a final check on this before cutting over in a separate PR.

Checklists

Which features or pages does this PR touch?
This won't change anything as-is, but when cut over, it will influence:

• Homeroom
• Core, authorization

Does this PR use tests to help verify we can deploy these changes quickly and confidently?

• Included specs for changes
• Improved specs for existing code in need of better test coverage
• Manual testing made more sense here

[kevinrobinson]

selfie