Updates needed for replacing hiredis in the valkey repo

[bjosv]

• Add SDS_INCLUDE_DIR and DICT_INCLUDE_DIR to be able to replace sds and dict.
• Handle sdsrange() API difference
  The sdsrange in Valkey return void and performs no length check.
• Use same return type as Valkey from the hashFunction in dictType
  Fixes issues on 32bit and macOS
• Update the nodeIterator memory blob to fit Valkeys larger dict iterator.

Changes needed in valkey repo:
valkey-io/valkey@unstable...bjosv:valkey:refs/heads/use-libvalkey

[zuiderkwast]

• Moved sds and dict to own directory.

• Add Makefile option USE_INCLUDE to be able to replace sds and dict with types provided in the Valkey repo.
  The build in valkey will use USE_INCLUDE=../../src/ (relative to deps) to provide its sds.h and dict.h.

Do they need to be in a separate sub directory? Can't they stay where they are and when it's built and linked by valkey, we just give precedence to valkey's own src dir?

I could also accept specific variables like SDS_INCLUDE_DIR, DICT_INCLUDE_DIR, etc. to explicitly indicate these two libs.

In your valkey branch, I don't see how you link libvalkey with valkey's sds and dict. When linking e.g. valkey-cli, we link to libvalkey.a, which is built without dict and sds?

[bjosv]

Do they need to be in a separate sub directory? Can't they stay where they are and when it's built and linked by valkey, we just give precedence to valkey's own src dir?

It should be possible, this was to follow the initial talks how it could be done. I'll try it so we can see how it looks.

In your valkey branch, I don't see how you link libvalkey with valkey's sds and dict. When linking e.g. valkey-cli, we link to libvalkey.a, which is built without dict and sds?

When building valkey-cli I added sds.o and sds's dependencies to ENGINE_CLI_OBJ.
When linking valkey-cli with libvalkey the linker already knows sds and since the cli is not using, nor will incorporate, the cluster.c or async.c code the dict type is not required.

ENGINE_CLI_OBJ=anet.o ... sds.o util.o sha256.o

[michael-grunder]

Looks good to me. Smaller surface area change than I would've guessed.