Fix type of connect to fully work, and to work with newer Flow.

[gnprice]

This is part of #3399. See also discussion in #3422 and #3428 .

The new RN version (v0.59) comes with a new Flow version (v0.92). That Flow version, in turn, comes with more consistent enforcement of an annotation requirement that (a) on the one hand means fewer bogus "Santa Claus" types ("everything the code wants to be true, is true!", aka empty) but (b) means a lot of boilerplate when using connect, if relying on the libdef for it in flow-typed upstream.

Moreover, the new upstream libdef for connect doesn't understand defaultProps, causing a lot of spurious type errors.

So with this branch, we bring in the new libdef... but then add our own wrapper around it, with an utterly trivial implementation -- if you erase all the types, it looks like this:

export function connect(mapStateToProps) {
  return connectInner(mapStateToProps);
}

but with a bunch of complexity in the types to describe what connect really does, plus about 500 words of comments.

Also marks with a fixme the remaining places where we have type errors hidden by the ineffective old type on connect. I fixed a bunch of such errors last week and the week before, before I realized how much work was needed on the type of connect itself; for the rest, this just marks them so we can move on and fix them separately.

---

Posting this as a PR because (a) I'd like to shift to more of a practice of posting my own changes for discussion before merge, and (b) this change in particular deserves some discussion, because I want everyone to be aware of it so there are no surprises when Flow complains about a type error on connect in the future.

[gnprice]

Also filed #3451 for the followup task of fixing the newly-exposed errors.

[gnprice]

Ah, I forgot there is one type of boilerplate that's still required for the new Flow version. It's rather milder than some of the alternatives, though. Specifically:

• When mapStateToProps actually takes a props parameter,
• then its return type needs to be annotated.

For example:

type SelectorProps = {|
  backgroundColor: string,
|};

type Props = {|
  narrow: Narrow,
  dispatch: Dispatch,
  ...SelectorProps,
|};

class ChatNavBar extends PureComponent<Props> {
/* ... */
}

export default connect((state, props): SelectorProps => ({
  backgroundColor: getTitleBackgroundColor(props.narrow)(state),
}))(ChatNavBar);

Even this annotation seems like it shouldn't fundamentally be necessary; but at least for now, and with Flow v0.92, I didn't succeed in finding a way to get Flow to infer this.

[gnprice]

Thanks @borisyankov for the brief discussion in audio chat the other day. Merged, after adjusting the main commit's message for the fact I mentioned above, that we do need a few annotations even with this version.

[gnprice]

BTW, just to help me close a tab with confidence -- here's a Flow playground link with some of my experiments that led to the type-wrapper in f8c9810. Most of the ideas wound up in f8c9810, and with much more explanation than I wrote down in the experiments; but there are a few ideas there that didn't end up being necessary.

[gnprice]

Even this annotation seems like it shouldn't fundamentally be necessary; but at least for now, and with Flow v0.92, I didn't succeed in finding a way to get Flow to infer this.

FTR based on some quick experiments just now, I can't actually reproduce why this part appeared to be necessary!

There is #3768, which is a Flow unsoundness bug (that we just recently spotted) affecting these places in our code; but adding SelectorProps doesn't seem to do any good with that. And when I apply the silly const y = () => <X />; workaround described on that issue, everything seems to get inferred perfectly fine with no SelectorProps annotation.