CNDB-17010: Fix CC4→CC5 memtable configuration loss during upgrade

[djatnieks]

What is the issue

CNDB-17010

What does this PR fix and why was it fixed

CC4 stored the memtable column in system_schema.tables as frozen<map<text, text>>, while CC5 uses text. During upgrades, binary-serialized map data is misinterpreted as UTF-8 text, causing memtable configurations to fall back to defaults.

Changes:

• Add MemtableParams.getWithCC4Fallback() to detect and parse binary map data using null-byte heuristic
• Add mapCC4ClassNameToCC5Key() to map CC4 class names (TrieMemtable, SkipListMemtable) to CC5 config keys
• Update SchemaKeyspace.createTableParamsFromRow() to use new compatibility method

[github-actions]

Checklist before you submit for review

• This PR adheres to the Definition of Done
• Make sure there is a PR in the CNDB project updating the Converged Cassandra version
• Use NoSpamLogger for log lines that may appear frequently in the logs
• Verify test results on Butler
• Test coverage for new/modified code is > 80%
• Proper code formatting
• Proper title for each commit staring with the project-issue number, like CNDB-1234
• Each commit has a meaningful description
• Each commit is not very long and contains related changes
• Renames, moves and reformatting are in distinct commits
• All new files should contain the DataStax copyright header instead of the Apache License one

[djatnieks]

I think that tables created with CC5 and the text memtable column could cause problems if that node is then downgraded back to CC4. I don't think the SCM setting handles this and not sure if it should.

[driftx]

I think we could do this with SCM at the schema level rather than at read time, such that we maintain the CC4 map approach when SCM is < 5 and then upgrade it away from the map when SCM is changed. This would be similar (but more involved) to the way we delay other schema changes with SCM now, and allows us to avoid the byte sniffing to detect the correct format. WDYT?

[djatnieks]

I think we could do this with SCM at the schema level rather than at read time, such that we maintain the CC4 map approach when SCM is < 5 and then upgrade it away from the map when SCM is changed. This would be similar (but more involved) to the way we delay other schema changes with SCM now, and allows us to avoid the byte sniffing to detect the correct format. WDYT?

Yes, that would be much better - and resolve the downgrade concern. I overlooked existing use of SCM to delay schema changes initially, but see them there now and give that at try.

[driftx]

Looks good, just a few more issues around backward-compatibility. We should perhaps add a test that covers those too.

[driftx]

Looks good, just one last thing I missed before.

[sonarqubecloud]

Quality Gate failed

Failed conditions
0.0% Coverage on New Code (required ≥ 80%)

See analysis details on SonarQube Cloud

[cassci-bot]

❌ Build ds-cassandra-pr-gate/PR-2261 rejected by Butler

---

3 regressions found
See build details here

---

Found 3 new test failures

Test	Explanation	Runs	Upstream
o.a.c.index.sai.cql.VectorCompaction100dTest.testOneToManyCompactionTooManyHoles[eb false] ()	NEW	🔴⚪	0 / 26
o.a.c.index.sai.cql.VectorSiftSmallTest.testCompaction[db false] ()	NEW	🔴⚪	0 / 26
o.a.c.index.sai.disk.v1.SegmentFlushTest.testFlushBetweenRowIds[aa] ()	NEW	🔴⚪	0 / 26

---

Found 4 known test failures