createUpdateDBOpsForThreadStoreThreadInfos consumes deprecatedConvertClientDBThreadInfoToRawThreadInfo, but based on the name createUpdateDBOpsForThreadStoreThreadInfos it's not clear that the function is only for handling "Legacy" RawThreadInfos. I should've made this more clear when I was doing the refactoring work.
We could modify these functions to handle both (previously known as) LegacyRawThreadInfos and MinimallyEncodedRawThreadInfos, but that would complicate the logic and make things tricky with flow types because we want to support Legacy -> Legacy, Legacy -> MinimallyEncoded, and MinimallyEncoded -> MinimallyEncoded migration functions. Whereas in the future we only care about MinimallyEncoded -> MinimallyEncoded migrations and supporting the legacy stuff just adds clutter.
It would also be good to keep these existing utilities "frozen" so we don't have to go back and test old migrations pre-minimalEncoding... which would be tedious and time consuming.
Personally think it makes sense to keep these utilities "frozen" in a deprecated-* file and introduce new functions that only handle MinimallyEncoded->MinimallyEncoded going forward.
This is kind of an opinionated decision, so adding @ashoat as reviewer to get his thoughts.
Depends on D11056