address feedback (any-cast stripMemberPermissionsFromRawThreadInfos instead of $FlowIgnore)

rebase and land

Here's the followup diff I promised: D12799

land

rebase before landing

rebase BEFORE re-removing any-cast

cherry-pick and land

cherry-pick and land

It's actually fine to land this as-is. If migration runs on RawThreadInfo that's already missing permissions, nothing will happen since stripPermissionsFromMemberInfo just won't really do anything:

rebase

rebase

rebase

rebase

rebase

rebase

rebase

Can drop this now, thanks @marcin !

cherry-pick and land

cherry-pick and land

cherry-pick and land

This is purely rename diff, so safe to cherry-pick and land out of order.

Did you perhaps forget to remove the any-cast before diffing this up?

remove extraneous any-cast

Updated test plan after some more testing.

fix logic, still need to do more testing

Lot of things that need to be fixed up here.

rebase after addressing feedback in previous diffs in stack, still need to fix this diff up

move changes to stripMemberPermissionsFromRawThreadInfo into this diff

update diff with ESLint and validator unit test resolved.

update to address ESLint and failing validator test. flow issue(s) still expected.

rebase

still would like to see the ESLint fix moved to the diff where the issue is introduced.

fix ESLint issue

rebase after landing validator fix

rebase before addressing feedback

Ran yarn eslint:all, yarn flow:all, and yarn jest:all locally and confirmed that they all passed without issue. Will wait for ESLint & Flow & Jest workflow to pass before landing.

cherry-pick and land, validator test should pass now

cherry-pick and land

Can also cherry-pick and land this to simplify stack before rebasing and addressing all feedback.

In D12594#361908, @ashoat wrote:

Hmm looks like a bunch of Flow errors

cherry-pick off master

Going to go ahead and try cherry-picking this onto master to fix the failing validator unit test and get rest of stack "more green."

rebase, look like there are no ESLint issues. There's failing validator that gets fixed in later diff... though maybe it makes sense to cherry-pick D12758 and land it to resolve failing validator test for rest of stack.

But it's inappropriate for use on the client, where we don't expect the keyserver to ever respond with the legacy format.

Second: it looks like there's a Flow error here that doesn't show up in the parent diff. Any context?

First: is rawThreadInfoFromServerThreadInfo just for the shimming logic that handles old clients?

address ESLint issues

rebase after resequence

rebase after resequence

resequence

In D12601#357386, @ashoat wrote:

I think it's better to have type suppressions than to have to maintain the old set of types indefinitely. This makes sense to me