When performing a manual run of a StatusUpdate, the code responding to

the manual run signal had no choice but to try to find a matching

IntegrationConfig for the review request. If multiple matches were

found, it had to pick one, and this could easily be the wrong one.
To solve this, we now store the configuration ID in

StatusUpdate.extra_data, using a private key. This is stored either

when setting the new StatusUpdate.integration_config property, or when

creating the StatusUpdate using

StatusUpdate.objects.create_for_integration() (which is the preferred

way going forward).
When either setting or fetching the configuration, the configuration is

validated to make sure it matches the same LocalSite, to avoid any

cross-site contamination issues.
The status_update_request_run signal is now given a config argument

mapping to this stored configuration (if one is stored), which

integrations can use. This will require a change for integrations

handling that signal to prioritize the new argument.
Old Status Updates in manual run mode will result in a None

configuration, which will need to be handled through legacy means, but

all future Status Updates created after this change will have a suitable

configuration.

All unit tests pass.
Tested this along with changes in rbintegrations to make use of the

new config state.
This will be tested in production with an affected customer.