Deduplicate "unknown prop" warning to ease pain of version updates

[flarnie]

Note: There are other PRs open to fix some failing tests and I expect to rebase on top of those and fix any remaining failures before landing. Hope folks can review this anyway in light of this.

Some widely used libraries which depend on React have used syntax that
ends up passing non-standard props to default React components like
'dom' and 'div'. For example:

  // where this.props contains attributes like 'foo'
  return <div {...this.props} />;

Since we started throwing warnings for this syntax in Reactv15.2 some
libraries have not upgraded past v15.2.

Now, because of deprecations in 15.5, some libraries will only work with
Reactv15.5, and this causes a conflict when other libraries are pinned
at v15.1. The overall effect is that either there are version conflicts
or the "unknown prop" warning is thrown all over the place, and users of
these libraries can't fix the warnings.

See #9466 for more context.

We are deduping this warning in hopes that it allows more library
authors to update to the latest version of React. React v16.0 may take a
different approach to this issue. For some related discussion, see
#9477

Test Plan:

• Added a unit test
• Manually tested with a fixture that was not committed; https://gist.github.com/flarnie/db011bf54206f30b9983cd4dc674c82e

Before submitting a pull request, please make sure the following is done:

1. Fork the repository and create your branch from master.
2. If you've added code that should be tested, add tests!
3. If you've changed APIs, update the documentation.
4. Ensure the test suite passes (npm test).
5. Make sure your code lints (npm run lint).
6. Format your code with prettier (npm run prettier).
7. Run the Flow typechecks (npm run flow).
8. If you added or removed any tests, run ./scripts/fiber/record-tests before submitting the pull request, and commit the resulting changes.
9. If you haven't already, complete the CLA.

[sophiebits]

Does this mean that if a third-party component warns first, then you'll never see any warnings for first-party code?

[gaearon]

Yea. IMO at this point it’s a reasonable tradeoff (most third party libs have updated long ago).

[flarnie]

Yea - there are definitely trade-offs with this approach. It sounds like there was some discussion on Twitter, and then on the issue as well. I think this is okayish for v15.6, but we may want to discuss more how to deal with this in v16.0.

[gaearon]

IMO we should completely switch to the new behavior in 16.0 (#9477). Then we won't need to come back to this warning at all.

[gaearon]

LGTM, thanks!

[flarnie]

Holding off merging this until the React core team discusses this approach more. @spicyj @gaearon

[gaearon]

Closing per discussion with @flarnie and #9466 (comment).