Show only annotations from current assignment by default

Currently Hypothesis fetches annotations based on the document URL/ID and group, and does not take into account the LMS assignment ID. This means that if the same content is re-used across multiple assignments, the same set of annotations will show up on each. This behavior was inherited from the way Hypothesis works outside of the LMS. We have been able to get away with it because most assignments in a course will use different content and in that case each assignment will show a unique set of annotations. However it is problematic for cases where content is re-used, because it is unclear to users which context a particular annotation was made in. Some examples of when this happens:

- A long document (such as a book or PDF) is re-used across multiple assignments, with each assignment focusing on a segment of the work.
- Content from a third-party provider is being used, and the instructor is not able to break up the content into units that match what they want to teach
- An instructor is intentionally re-using the same content, but setting a different task for each assignment

This issue proposes to change the behavior so that **by default, Hypothesis will only show annotations from the current assignment.** This change would have a number of benefits:

- It is aligns with the conceptual model that many of our users probably already have about how Hypothesis works
- It aligns with how we talk about user activity in various contexts (eg. we send out notifications to instructors saying "your students made 5 annotations on assignment X")
- In the context of assignments that are graded, it means that only the relevant student work (ie. annotations made in the context of a particular assignment) is shown when the teacher is grading
- When instructors are teaching long documents or books, it avoids the distraction of showing annotations from other assignments using the same content
- It makes it easier to support use cases where the same content is intentionally re-used but with different tasks
- Storing the data needed to support this could also enable capabilities such as grouping annotations by assignment in a future notebook iteration

As discussed in [this Slack thread](https://hypothes-is.slack.com/archives/C2BLQDKHA/p1699268047455859) there are some use cases when it would be useful to surface annotations from the same content in other assignments. For example:

- A student wants to export all the notes they made on some content. It would be annoying if they had to collate notes from across multiple assignments
- An instructor creates two assignments using the same the content, and the student or teacher want to consult their notes from the other assignment

## Migration

There are some constraints to consider in making this change:

- We only recently (November 2023) started recording the LMS assignment ID as metadata with annotations. For annotations created earlier we cannot uniquely identify which assignment they are associated with.
- Although this change would not be noticeable in most assignments, because they don't use the same content as another assignment in a course, it is a significant conceptual change to how Hypothesis works and we want to avoid causing disruption while an assignment is in the middle of being completed

For these reasons, my thinking is that this new behavior would be limited to assignments created after some cut-off date which is later than when we started recording assignment ID associations with annotations.

If we provided a way to show annotations from all assignments on a document, then conceptually the fallback behavior is equivalent to forcibly turning that option on.

## Related discussions

Slack thread in #prod-general with the initial proposal: https://hypothes-is.slack.com/archives/C4K6M7P5E/p1699266629799979
Slack thread in #support soliciting feedback on making this change: https://hypothes-is.slack.com/archives/C2BLQDKHA/p1699268047455859

## Implementation notes

We currently record assignment ID with annotations by having the LMS app pass an opaque blob of JSON to the client which is then posted to h and stored as a schemaless JSON blob in h's DB. This is convenient and flexible from the LMS app's perspective, but doesn't robustly guard against mistakes in transiting the data and doesn't allow efficient filtering on the h side. If we are going to start using this to affect what the user sees when they load an assignment, we are going to need to store the data in h in a way that is more robust and allows more efficient querying.

One general idea I had was based on the observation that there is a correspondence between data model concepts in h and lms, with the h equivalents being more general. eg. The lms app has students and teachers. h has users. The lms app has courses and reading groups, h has groups. We could take a similar approach with assignments. The LMS app knows about assignments, h would know about _activities_ or _contexts_. An assignment would have an associated activity/context ID (some kind of URI) which could be filtered on. Alternatively we could just introduce an explicit "assignment" concept in h.