bug: spilled data may be skipped on storage get

[hzxa21]

Describe the bug

When introducing memtable spill, we have structure kv-entry epoch to be (epoch_from_barrier, spilled_offset). For each epoch_from_barrier, we increment the spilled_offset per memtable spill to ensure that data spilled within the same epoch_from_barrier has different spilled_offset

However, in storage get, the read epoch provided is purely epoch_from_barrier with spilled_offset == 0 and we use it to construct a full key, which later will be used in a SstableIterator::seek. This will caused data with spill_offset > 0 to be skipped.

Example:

Assume we have a SST:

key1 (epoch_from_barrier = 1, spilled_offset = 0)
key2 (epoch_from_barrier = 1, spilled_offset = 1)
key3 (epoch_from_barrier = 1, spilled_offset = 1)

get key2 with (epoch_from_barrier = 1) should see key2 in the SST but SstableIterator::seek will point to key3 because seek key is key2 (epoch_from_barrier = 1, spilled_offset = 0)

Error message/log

No response

To Reproduce

No response

Expected behavior

No response

How did you deploy RisingWave?

No response

The version of RisingWave

No response

Additional context

No response