Add proper error handling / warnings in JSON functions

A part of the previous discussion is below. We need a decision (and implementation, if we decide for it) before it goes RC.

Alexey Botchkov
Another difference from MySQL is that MariaDB's JSON functions never launch errors. Just return NULL in that cases.
Actually i don't see how these error messages are helpful for users, so don't think at the moment we need them at all.

Elena Stepanova
Error messages are helpful to users in the exact same way as any other error messages with a meaningful text are helpful. They explain what is wrong, instead of making a user guess why they return whatever they return. That's why any error messages exist.
...
I know that the standard suggests "NULL ON ERROR" as default behavior, but the whole point of default is that somebody can override it. If we don't offer this option, we can't go with silent mode only. If you want to fully implement the ON ERROR clause, it will be another story.

Sergei Golubchik
I'd fully expect us to implement the ON ERROR clause eventually. When we extend a partially implemented feature it's usually in the direction of being more standard compliant.
So, I'd prefer any partially-compliant feature not to have any behavior that directly contradicts the standard. If we'll have ERROR ON ERROR by default now, then later, when ON ERROR clause will be implemented, we will need a new sql_mode (JSON_NULL_ON_ERROR) or a new server variable @@json_on_error='NULL' to allow users to preserve the old historical-but-standard-incompatible behavior.
On the other hand, our JSON_OBJECT() syntax is non-standard and MySQL-compatible. But it can be extended to be standard compliant without breaking the backward compatibility. That's why we can implement MySQL-compatible syntax now and extend it later, as needed, without breaking any existing applications.

If you are really so determined to stick to the standard, make it return NULL, but produce warnings. Warnings don't contradict the standard, do they?
We can make it either obey STRICT_ALL_TABLES (personally I don't like it, because it often has nothing to do with tables, but sadly it's already wide-spread), or add another STRICT_JSON or whatever, which would convert them to errors.
I think that's the case where we should stick to the common practice and common sense rather than to the letter of standard, at least while the implementation is only partial. This "eventually", when we expect to implement the ON ERROR clause fully, might happen years from now, or, quite likely, never.
Without error handling, the behavior is utterly confusing. How is anyone supposed to know whether the result they are getting is real (e.g. a document does not contain the path), or it's because the document is invalid?