We've been seeing an issue where users have hit errors during the

process of diff migration where a referenced LegacyFileDiffData

referenced by a FileDiff is missing in the database. These are in

requests that follow a successful migration, pointing to a potential

race condition where one request migrated a diff and the other then

tried with stale data.
If the migration can't find the LegacyFileDiffData associated with a

request as part of the migration process, it will instead try to reload

the new RawFileDiffData IDs from the database and inject them into

the FileDiffData. It will sanity-check whether there are proper values

to find, erroring out if not.
It also fixes the save calls for FileDiffs. We had a bunch of

save(update_fields=[...]) calls sprinkled around, but these weren't

doing anything special, since we didn't propagate update_fields to the

parent. We now do this in an effort to prevent another case where

migrated IDs could be overridden.

Wrote a unit test that exhibited the same problem that we've seen in

the logs. It passes with this fix.
All other unit tests pass as well.
Simulated missing database entries with keys still set. Saw the error

information. (Callers still fail, since there's no diff to get, but

it's clear something went wrong, and IDs are provided.)