fix hincrbyfloat not to create a key if the new value is invalid

[chendq8]

Check the validity of the value before performing the create operation, prevents new data from being generated even if the request fails to execute.

[enjoy-binbin]

can you add some top comment to describe the problem?
didn't bother to read through the code

[oranagra]

indeed. a detailed comment would help. @chendq8 please update.
looking at the test, i realize you found a bug in which a command can fail (return an error), but it could happen after already performing a medication to the database.

however, i don't think i like the way to fixed it (changing hashTypeLookupWriteOrCreate to it's components).
how about just copying the isnan and isinf to the top?
i.e. if the input isn't Inf or NaN, then adding 0 won't change it to be one of them.
or in other words, the first check will check the input, and the second one will only be relevant if the key already exists.

it does mean that we'll affect the error, e.g. cases that in the past would result with WRONGTYPE, will now be rejected with the NaN/Inf error, but i don't think that's an issue.

[chendq8]

indeed. a detailed comment would help. @chendq8 please update. looking at the test, i realize you found a bug in which a command can fail (return an error), but it could happen after already performing a medication to the database.

however, i don't think i like the way to fixed it (changing hashTypeLookupWriteOrCreate to it's components). how about just copying the isnan and isinf to the top? i.e. if the input isn't Inf or NaN, then adding 0 won't change it to be one of them. or in other words, the first check will check the input, and the second one will only be relevant if the key already exists.

it does mean that we'll affect the error, e.g. cases that in the past would result with WRONGTYPE, will now be rejected with the NaN/Inf error, but i don't think that's an issue.

The implementation mode has been modified.

[zuiderkwast]

LGTM