Scylla: Materialized view updates use incorrect schema to interpret writes after base table schema is altered

[tgrabiec]

If the materialized view's primary key includes a regular column of the
base table, then after changing the base table's column set (add/drop) the view
update will use incorrect ids, which may cause aborts, segfaults, write failures
or data of the wrong column landing in the view.

The view_info object, which is attached to the schema object of the
view, contains a data structure called
"base_non_pk_columns_in_view_pk". This data structure contains column
ids of the base table so is valid only for a particular version of the
base table schema. This data structure is used by materialized view
code to interpret mutations of the base table, those coming from base
table writes, or reads of the base table done as part of view updates
or view building.

The base table schema version of that data structure must match the
schema version of the mutation fragments. That's currently not the case
after the base table is altered because the view schema will not change
when the base table is altered and this data structure will not be recalculated.

[tgrabiec]

I already have a patch for this.

[bhalevy]

@scylladb/scylla-maint ping backport

[avikivity]

Backported to 4.2, will wait before backporting further.

[bhalevy]

@avikivity the fix probably got enough soak time, we'd like to backport it eventually to 4.0

[avikivity]

Agree three weeks is plenty, will backport to 4.1 and 4.0.

[avikivity]

Backported to 4.0, 4.1.