MDEV-38117: Replication stops with ERROR when Primary Key is not defined in Multi Master

[bnestere]

hen replicating tables with different structures between a master and
slave (via binlog_row_metadata=FULL, i.e. MDEV-36290), if the table
didn't have any keys, replication could break from a
Can't find record in '<table>', Error_code: 1032;
error. This was due to the table's internal tracking of provided values
(i.e. TABLE::has_value_set) persisting across transactions. I.e., when
applying a new row event, the has_value_set bitset would start in a
state indicative of the last event. Then, if the new row event required
first finding a row, the has_value_set could represent a larger bitset
than what was actually unpacked from the master. More specifically, if
the last row event inserted something into the table, where slave-only
columns would be given default/auto-generated values, these would
update the TABLE::has_value_set. However, when the next row event would
come in, those auto-generated values from the last transaction would
not be present, but the row-search would include them to look-up the
row, and not be able to find anything.

This is fixed by resetting the table's internal state of provided
values (TABLE::has_value_set) before unpacking the row data. Doing so
revealed a bug where unpacked fields which explicitly provided NULL
values would skip indicating that an explicit value was provided
(and thereby couldn't be found by find_row()). To fix this, the
slave-side field will always call has_explicit_value() if it is
present in the packed data.

Note to reproduce the second bug, only apply the reset_default_fields()
part of the patch, and then run tests rpl.rpl_row_rec_comp_myisam and
rpl.rpl_row_rec_comp_innodb.

This PR is organized as follows:

1. Commit 1 contains a test case with the regression to show the problem
2. Commit 2 contains the fix and .result file for the regression

FWIW, AI auto-reviewed this patch with conclusion

This is a solid contribution that resolves a critical replication bug. The analysis is accurate, the fix is robust, and the test coverage is excellent. My recommendations are minor and aimed at enhancing code clarity for future maintenance. I approve of these changes.

It's recommendations didn't make sense though.