Reduce use of assertions in prop parsing

[motiz88]

Summary:
Changelog:
[General][Fixed] - Invalid prop values no longer trigger assertion failures in Fabric

Context

Fabric has historically been very strict about prop parsing. It originally abort()ed on any prop value that failed to parse according to the expected type; this was replaced with dev-only assertions in D27540903 (cb37562). We've received feedback that C++ assertions (and other similar mechanisms in the legacy renderer) are still too aggressive and disruptive as a diagnostic for developers working on JS code.

We are changing React Native to behave more like a browser in this regard, reflecting a new principle that bad style values are not runtime errors. (See e.g. D43159284 (d6e9891).) The recommended way for developers to ensure they are passing correct style values is to use a typechecker (TypeScript or Flow) in conjunction with E2E tests and manual spot checks.

More broadly, values passed from JS product code should not be able to crash the app, which is why we're not strictly limiting this change to style props. From now on, if a JS developer can trigger an internal assertion in React Native simply by writing normal application code, that is a bug.

This diff

This diff introduces a new macro called react_native_expect which serves as a drop-in replacement for react_native_assert, but logs (to glog / logcat / stdout) instead of asserting. This way we don't need to fully delete the existing call sites. This will be helpful if we decide that we want to repurpose these checks for a new, more visible diagnostic.

I'm intentionally opting for the simplest possible improvement here, which is to silence the assertions - not to print them to the JS console, not to convert them to LogBox warnings, etc. The hypothesis is that this is already strictly an improvement over the previous behaviour, will help us get to feature parity between renderers faster, and allow us to design improved diagnostics that are consistent and helpful.

Next steps

1. There are still places where Fabric can hit an unguarded assertion in prop conversion code (e.g. unchecked casts from RawValue with no fallback code path). I will fix those in a separate diff.
2. Paper on iOS needs a similar treatment as it calls RCTLogError liberally during prop parsing (resulting in a native redbox experience that is nearly as bad as an outright crash). I will fix that in a separate diff.
3. I'll add some manual test cases to RNTester to cover these scenarios.
4. We will eventually need to take a clear stance on PropTypes, but since they provide reasonable, non-breaking diagnostics (recoverable JS LogBox + component stack) it is less urgent to do so.

Reviewed By: sammy-SC

Differential Revision: D43184380

[facebook-github-bot]

This pull request was exported from Phabricator. Differential Revision: D43184380

[analysis-bot]

Platform	Engine	Arch	Size (bytes)	Diff
android	hermes	arm64-v8a	8,485,596	+0
android	hermes	armeabi-v7a	7,806,383	+0
android	hermes	x86	8,962,827	+0
android	hermes	x86_64	8,819,803	+0
android	jsc	arm64-v8a	6,699,334	+0
android	jsc	armeabi-v7a	7,490,840	+0
android	jsc	x86	9,223,977	+0
android	jsc	x86_64	6,924,567	+0

Base commit: 89ef5bd
Branch: main

[facebook-github-bot]

This pull request has been merged in d16c1a0.