Add associated document id field to ChangeMeta

[mjriley]

Product Description

Technical Summary

Associated ticket: https://dimagi-dev.atlassian.net/browse/SAAS-15054.
This adds an associated_document_id to all ChangeMeta objects that allows us to link case changes to the forms that triggered them. It is meant to be somewhat generic, because ChangeMeta is used by more than just cases.
Note that this PR is difficult to roll back -- while existing kafka changes will simply send a None value for the new field, if this change were to be reverted, anything with a set associated_document_id would fail to wrap into a ChangeMeta.
For this reason, I've isolated just this field change to this PR, and intend to create a separate PR for moving the duplication logic between processors.

Safety Assurance

Safety story

Verified through local testing that the additional field is added and processed correctly. Also verified that changes without the field will be processed without issue with this change. This specific change shouldn't introduce any significant overhead, as we're only slightly expanding the size of a ChangeMeta. The potential performance impact would mainly be from using the associated_document_id to fetch forms within the case processor.

Automated test coverage

Did not feel tests were needed here, but perhaps there's an argument for creating tests that verify kafka changes can still be wrapped with the new field?

QA Plan

No QA planned

Rollback instructions

Rollback of this PR would be difficult, because any changes published with this change will fail to be wrapped to the previous version of ChangeMeta. I think if we really wanted to force a revert and did not want to lose data, we'd need to create a custom wrap function for ChangeMeta that ignored the associated_document_id field.

Labels & Review

• Risk label is set correctly
• The set of people pinged as reviewers is appropriate for the level of risk of the change

[snopoke]

If you're concerned about the rollback issue there are a few options:

1. Set _allow_dynamic_properties to True on ChangeMeta
2. Override ChangeMeta.wrap to cache wrapping exceptions and retry with the new key removed.

[mjriley]

If you're concerned about the rollback issue there are a few options:

1. Set _allow_dynamic_properties to True on ChangeMeta

Thanks for this. This seems like a good approach. Do we think there's a good reason to keep ChangeMeta strict? I'd imagine allowing dynamic properties would need to be done by an earlier commit so that rolling back this PR doesn't break anything

[snopoke]

If you're concerned about the rollback issue there are a few options:

1. Set _allow_dynamic_properties to True on ChangeMeta

Thanks for this. This seems like a good approach. Do we think there's a good reason to keep ChangeMeta strict? I'd imagine allowing dynamic properties would need to be done by an earlier commit so that rolling back this PR doesn't break anything

Yes, that's correct. I don't see a reason to keep it strict.

[mjriley]

I've merged a new PR into master that lets ChangeMeta accept dynamic properties, so this PR should now be safe to roll back, if required