[lib] Introduce RawThickThreadInfo type
1d0d22eb214c
Actions

Description

[lib] Introduce RawThickThreadInfo type

Summary:
This diff splits RawThreadInfo into RawThinThreadInfo (basically the old type) and RawThickThreadInfo, which will be used for E2E-encrypted DMs.

The latter type includes ThreadSubscription for each member.

I tried to break this diff down but it was tough due to Flow issues.

This diff doesn't update ThreadInfo. That type is used generally in frontend code, and I'm not sure we'll need the new ThreadSubscription.

This diff also doesn't do anything to make sure we handle RawThickThreadInfo correctly when we encounter it. That will be handled in later tasks. It's okay to commit this type change now as we aren't actually introducing RawThickThreadInfo to any stores.

On the Flow side here, I had to add a thick: true attribute. I initially tried to differentiate the two types through the type field, which should let us represent RawThreadInfo was a union of two disjoint types (RawThinThreadInfo and RawThickThreadInfo). But I wasn't able to get Flow to narrow the types when I checked the type field. Here's what I tried:

Enumerating all of the possible values of type at every location, for both the thick and thin conditions. This worked but was way too verbose
Considered using type guards, but our setup doesn't support them yet. More details in this blog
Considered using an older version of type guards: assert functions that use %checks. However this wasn't able to narrow a threadInfo by checking threadInfo.type for some reason
Considered using assert functions that just have invariants and anys instead of %checks. This resulted in four functions: assertThinRawThreadInfo, assertThickRawThreadInfo, assertLegacyThinRawThreadInfo, assertLegacyThickRawThreadInfo. A pair of these would be combined with a threadTypeIsThick check. Ultimately decided it was too verbose
Referenced this GitHub issue where something similar is discussed