Set Command with IFEQ Support

[sarthakaggarwal97]

This PR allows the Valkey users to perform conditional updates where the SET command is completed if the given comparison-value matches the key’s current value.

Behavior with this PR

SET <key> <value> IFEQ <comparison-value>

If the values match, the SET completes as expected. If they do not match, the command returns a (nil).

Behavior with Additional Flags

1. SET <key> <value> IFEQ <comparison-value> GET returns the existing value if present, (nil) if not and gives the error if there is a Type Mismatch. Conditional set operation is performed if the given comparison value matches the existing value.
2. SET <key> <value> IFEQ <comparison-value> XX returns nil if the key doesn't exist, otherwise conditionally updates the key if the given comparison value matches the existing value.
3. SET <key> <value> IFEQ <comparison-value> NX returns nil whether or not the key exists. Does not conditionally update the key if NX flag is present

Addresses: #1215

[hpatro]

Would be nice to think through the behavior with other flags/parameters of SET command https://valkey.io/commands/set/

NX -- Only set the key if it does not already exist - should we error in this case if CAS is provided?
XX -- Only set the key if it already exists - This becomes redundant to use I believe with CAS.
GET -- Return the old string stored at key, or nil if key did not exist. An error is returned and SET aborted if the value stored at key is not a string. - I think we need to support this parameter in some form. The scenario which comes to my mind is when CAS fails and a user doesn't need to send a GET command again to find out the value stored in the engine. However, we need to think about how to differentiate between success scenario vs failure scenario.

Also, we need to document them.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 70.76%. Comparing base (4986310) to head (3dc3407).

Additional details and impacted files

@@             Coverage Diff              @@
##           unstable    #1324      +/-   ##
============================================
+ Coverage     70.68%   70.76%   +0.07%     
============================================
  Files           115      115              
  Lines         63177    63198      +21     
============================================
+ Hits          44657    44722      +65     
+ Misses        18520    18476      -44     

Files with missing lines	Coverage Δ
src/commands.def	100.00% <ø> (ø)
src/t_string.c	96.88% <100.00%> (+0.13%)	⬆️

... and 18 files with indirect coverage changes

---- 🚨 Try these New Features:

• Flaky Tests Detection - Detect and resolve failed and flaky tests
• JS Bundle Analysis - Avoid shipping oversized bundles

[hpatro]

@sarthakaggarwal97 Please avoid force pushing. force push removes the reviewer's history in Github and one needs to look at the entire change again.

[sarthakaggarwal97]

noted @hpatro, will avoid it.

[hpatro]

Thanks @sarthakaggarwal97 for the PR! Looks pretty good. Could you also document the behavior in the top comment. Will be easier for others to review and we can finalize it.

[hpatro]

@valkey-io/core-team On failure of compare/set instead of nil value we should return an error with old value in it. Otherwise, a client would need to perform another GET operation.

[enjoy-binbin]

return an error with old value seems odd to me. i think in normal cases, a client is unlikely get an error in set IFEQ, they hold the old value in somewhere, and if the old value is unvalid, this mean client should abort the set, this usually means the client should abort the entire business logic. In this case, client should GET the new value as needed and usually they don't really need the new value, they juse want the result of whether the SET succeeded or not.

[hpatro]

@enjoy-binbin I understand if the value is updated from a DB to Valkey as a cache, the client won't benefit much from the value present.

However, if I think Valkey being used as a datastore and value is updated by multiple clients based on the value stored (let say increment old value by 1). for this case, they would need to know the previous value.

Let's hear other devs opinion on this and resolve this.

[hpatro]

LGTM overall. The behavior currently is:

1. if value matches, set the new value.
2. If existing value is of different type, return error WRONGTYPE Operation against a key holding the wrong kind of value
3. if existing value is a mismatch, return nil. (want us to finalize on this).