convertThreadStoreThreadInfosToNewIDSchema calls the utility function convertRawThreadInfoToNewIDSchema where both the input and output is any.
convertThreadStoreThreadInfosToNewIDSchema is called from createUpdateDBOpsForThreadStoreThreadInfos which expects a migrationFunc: RawThreadInfos => RawThreadInfos.
Rather than updating convertThreadStoreThreadInfosToNewIDSchema and all of those re-usable migration utils to support this legacy migration, I typed convertThreadStoreThreadInfosToNewIDSchema as accepting RawThreadInfos and have an invariant that enforces that we'll never actually pass a minimallyEncodedRawThreadInfo through this function.
NOTE: I think this might be one of the more "controversial" changes I'm making to flow issues. It's kind of a lazy approach since I'm assuming that it's reasonable to assume convertRawThreadInfoToNewIDSchema won't be used in new migrations... so we're "lying" to flow by saying it accepts MinimallyEncodedRawThreadInfos and then immediately failing with an invariant if one is actually passed through. I still think this is cleaner than some of the other refactoring approaches I tried which required more involved changes to eg createUpdateDBOpsForThreadStoreThreadInfos. Would love to hear thoughts from @ashoat, @tomek, @michal if there are any approaches that would be better.
[skip-ci]
Depends on D10281
