Unexpected behavior of WriteBatch wrt rows violating schema constraints

While decoding write operation sent using WriteRequestPB, tablet servers reject the whole batch if there is a row that violates table schema constraints (e.g., presence of null values for non-nullable columns). That behavior is different from the case when errors happen at later stages of 'applying' received write operations (e.g., a duplicate key error). In most cases, the user expects only 'bad' rows to be rejected, but in case of schema violation constraints whole batch of operations received by a tablet server is rejected. Maybe, that behavior should be configurable, but at least there should be an option to reject only the 'bad' rows and most likely that should be the default. Current behavior violates the POLA principle and should be fixed.

A reproduction scenario in Groovy for the described behavior using Java Kudu client is at https://gist.github.com/boristyukin/8703d2c6ec55d6787843aa133920bf01

Another reproduction scenario uses C++ client: see the attached example.cc file. The example can be compiled as an example C++ Kudu client application; see instructions at https://github.com/apache/kudu/blob/master/examples/cpp/README.adoc