[WIP] fix: RENAME crash with concurrent blocking commands

[vyavdoshenko]

Fix crash in Renamer::DeserializeDest when RENAME runs concurrently with blocking commands like BRPOPLPUSH.

The bug: RENAME caches destination key existence in phase 1 (dest_found_), but between phases, another transaction can create/delete the key. Using stale cached value in phase 2 causes a crash when trying to delete a non-existent key.

The fix: Check current key state via dest_res.it.is_done() instead of relying on stale dest_found_ from phase 1.

Fixes: https://github.com/dragonflydb/dragonfly/issues/6182

[romange]

@vyavdoshenko it should not happen. Another transaction should not be able to delete the key that is being changed by rename as we lock these keys for mutations. I suggest that you sync with @dranikpg to discuss this.

[dranikpg]

Its something we know, BRPOPLPUSH is the only command that has two hops and a write phase after unblocking and it doesn't respect transactions

[romange]

Can you provide (simulate) the possible order of operations that causes such bug?

[dranikpg]

Any order, once BRPOPLPUSH extracted a value, it will do a second hop and push it. While doing so, it doesn't check the continuation transacton, it just executes in PollExecution. You can for example start a script reading from DEST and then unnblock a BRPOPLPUSH SCR DEST and the script will see it, even though it was supposed to be atomic