Add tests (and fix bugs) for commands WRONGTYPE'ing appropriately against Vector Sets

[kevin-montrose]

Most commands, when used on Vector Sets, should WRONGTYPE. Similarly, Vector Set commands when used on non-Vector Set keys should WRONGTYPE

We have a bunch of commands, and we've been pretty laxidasical about checking GarnetStatus so this is a pretty big PR, though mostly mechanical.

Changes:

• Add tests for all Vector Set commands operating on non-Vector Set types
• Implement VCARD
• Implement VISMEMBER
• Sketch out VLINKS, VRANDMEMBER, and VSETATTR - far enough to WRONGTYPE, but not fully implemented
• Add tests for (most) non-Vector Set commands on Vector Set keys
• Add tests to validate the commands that overwrite Vector Sets (SET, MSET, etc.) correctly free up their resources

---

Overwriting Vector Sets is a more complicated operation - if the value is still in memory, a IPU or CU needs a preceeding delete (because the RecordType is changing); while if the value is on disk the blind upsert is fine, but we need to cleanup the Vector Set at some later point.

My solution is to fail IPU/CU's with a WRONG_TYPE result and then retry in a transaction, and to implement ICompactionFunctions.IsDeleted on GarnetRecordType to cleanup Vector Sets which are unreachable but not explicitly tombstone'd.

This approach is taken for:

• MSET
• PSETEX
• SET
• SETEX
• SETIFGREATER
• SETIFMATCH
• SETWITHETAG

This impacted one RI test ; I left this commented out with a TODO for review by someone with more RI knowledge.

---

Follow up work from discussion:

• rename ICompactionFunctions.IsDeleted -> IsDeletedBeforeCompaction(in TSourceLogRecord logRecord)
• combine ICompactionFunctions and IRecordTriggers

[Copilot]

Pull request overview

Copilot reviewed 48 out of 48 changed files in this pull request and generated 5 comments.