perf: skip task queue metadata blob write and serialization in CreateTasks

[mykaul]

Summary

• Commit 1: Remove the TaskQueueInfo proto blob write from the Cassandra CreateTasks CAS batch. Only the range_id fencing token is needed for the conditional check — the full blob (~200-300 bytes) was written unnecessarily on every CreateTasks call.
• Commit 2: Skip TaskQueueInfo blob serialization in the middle persistence layer, since no store backend needs it after commit 1.

Motivation

The CreateTasks path is the hottest write path in the matching service. Every task dispatch writes the full TaskQueueInfo proto blob as part of the CAS batch, but only range_id is used for fencing. This adds unnecessary serialization cost and increases Paxos/Raft proposal payload size.

This matches the SQL backend behavior, which already returns UpdatedMetadata: false and relies on SyncState to periodically flush metadata changes.

Approach

• Introduces templateCheckRangeIDQuery that only sets range_id in the CAS UPDATE, removing task_queue and task_queue_encoding columns from the hot path.
• The middle layer (task_manager.go) no longer serializes the TaskQueueInfo blob since no store consumes it.
• Commit 2 depends on commit 1 — without the store-level change, the Cassandra V1 store would panic on nil blob access.

Testing

• Cassandra persistence tests pass.
• Matching service compiles cleanly.
• Includes a new test TestCreateTask_DoesNotWriteTaskQueueMetadata verifying metadata is not written during CreateTasks.

[mykaul]

I've tested this extensively with ScyllaDB 2026.1, Cassandra 5.0 and Cassandra 3.11, running multiple Omes workloads - short periods of multiple workloads.

[dnr]

Fyi, we're discussing this internally. There's no correctness concern, but there is some concern about metadata updates happening less frequently, mostly about the backlog size. We might want to do a compromise and skip this sometimes but not always.

Do you have any numbers to quantify the improvements you saw? How did you notice this issue in the first place?

[mykaul]

Fyi, we're discussing this internally. There's no correctness concern, but there is some concern about metadata updates happening less frequently, mostly about the backlog size. We might want to do a compromise and skip this sometimes but not always.

Do you have any numbers to quantify the improvements you saw? How did you notice this issue in the first place?

AI noticed the potential improvement as I was working to improve the performance of ScyllaDB with Temporal (see #8652 ).
I'm testing every commit by itself, with all 3 DBs - see #9482 (comment) (I did not push all of them in order not to flood the team with PRs)

Do note that I do NOT feel I'm able to truly saturate the environment - it's either my pathetic laptop or the setup - or omes, which fails to properly load the system (ref #8652 (comment) )