There was a bug about invalid bar update operations. Bar update is
a single update operation with non empty isolated JSON path.
Isolated JSON path means that it does not interleave with any
other update operation in the same update/upsert() call.

In case bar update fails, there were 2 outcomes:

- it could crash in several places, when JSON path was invalid, or
  a type assumed in the JSON path didn't match the actual type
  (such as [...] applied to a scalar value);

- it could log error and all, but in the end still saved the
  operation result like if it was '='. For example, invalid '+'
  would behave just like '='.

The errors were happening for upsert() only, because this call
never treats client errors as errors. Instead, they are just
ignored. Bad JSON - ignore, integer overflow - ignore, and so on.
Are not ignored only client errors found during operation
decoding.

The expected behaviour is that such invalid operations are
skipped. Note, that it is possible, that some operations are
skipped and some are not.

The patch adds a 'finish' phase to bar field update. This is
based on the fact that bar is *always* created from a nop field
(not updated, part of the old tuple). So it is enough to leave
this field nop, if something goes wrong.

With all the other field types all is fine. They already do that
when apply an operation.

It is worth mentioning that even if during an attempt to apply an
invalid operation the update tree was changed anyhow, this is ok.
Structure changes don't affect the final result. For example, it
is ok if a rope field in an array will be split in 2. It is also
fine if a bar field is branched into route -> bar. This is fine
if a map field sequence will be split in 2 sequences.

Closes #5135