Log non-fatal error when fields are missing from written results

[benjamn]

Fixes #8331 and #6915 by relaxing an overzealous exception to be merely an invariant.error message, which should also help with the underlying cause of #7436 (comment).

Although this change is likely to trigger a number of new missing field error messages for existing applications, these errors are almost always worth investigating, because they can hide gaps in the incoming data that manifest themselves as missing fields later, when the original cause of the error is much less obvious.

Because this error was an exception before, we had to be very careful about when we threw it, since it would abort the entire write. Unfortunately, this carefulness led to some dodgy decisions about when to hide exceptions that really should have been surfaced (see #8331 for one example, where merely using possibleTypes would enable the exception). Now that we're just logging an error message using invariant.error, those messages can be a little noisier without disrupting the overall work of the client/cache.

In production, invariant.error messages are stripped out, along with invariant.warn and invariant.info, so these errors should never be visible in production builds (unlike the previous exceptions, which were thrown the same way in both production and development builds).

I hope developers find these error messages useful, though of course we can continue to refine the preconditions/frequency of the messages, and/or ways to capture/redirect errors for certain writes, where the errors are known to be harmless, or need to be programmatically processed in some way.

[benjamn]

One of the most common mistakes surfaced by these errors is providing only the mutation field's value (carData), rather than the field itself ({ addCar: carData }), when providing an optimisticResponse.