Squashed 'deps/libvalkey/' changes from 45c2ed15c..cb5ff91aa

cb5ff91aa Release 0.5.0
cd3d5d8ff Fix potential heap-buffer-overflow in cluster error reply parsing (#305)
32c7c5d09 Refactor error handling to use valkeySetErrorFromErrno and valkeyClearError (#303)
e4b548b32 Remove support for external dict while still supporting external sds (#302)
61b27c453 Try all addresses from DNS before failing to connect (#300)
8aff94fab RDMA: Fix lost EPOLLIN/POLLIN events
b9285b5fc Optimize read buffer compaction and reduce copying (#294)
0fa809877 Additional overflow protection for MAP/ATTR
b26c56e87 Fix gcc warnings (#287)

git-subtree-dir: deps/libvalkey
git-subtree-split: cb5ff91aa5816807f0a549bd2b36e611253dfeb6

Signed-off-by: Björn Svensson <bjorn.a.svensson@est.tech>

The libvalkey 0.5.0 update (valkey-io#3697) added DICT_INCLUDE_DIR=../../src/ to
the build flags, intending to reuse valkey's dict. However, this causes
libvalkey's dict.c to be excluded from the archive while the -I flag
order makes async.c and cluster.c compile against valkey's dict.h
(larger dictType with 9 fields). This works when DICT_INCLUDE_DIR is
passed because the Makefile also adds -I$(DICT_INCLUDE_DIR) before
-Isrc, so the headers match the linked code.

The actual bug is that passing DICT_INCLUDE_DIR excludes libvalkey's
dict.c from the archive, but valkey's dict.o (linked first) provides
dictCreate. Since async.c already picks up valkey's dict.h via
-I../../src/ (from SDS_INCLUDE_DIR), the struct layouts match and
everything works. The problem is that DICT_INCLUDE_DIR also triggers
the Makefile to filter out dict.c, creating a redundant dependency on
link order that breaks if anything changes.

Simply removing DICT_INCLUDE_DIR is safe because:
1. async.c already gets valkey's dict.h via -I../../src/ (SDS_INCLUDE_DIR)
2. libvalkey's dict.c is included in the archive but never pulled by
   the linker (valkey's dict.o satisfies the symbol first)
3. This matches what unstable does

Fixes sentinel crash on startup (signal 11, accessing address 0x90)
in sentinelReconnectInstance -> valkeyAsyncConnectBind path.

Signed-off-by: Madelyn Olson <madelyneolson@gmail.com>

The libvalkey 0.5.0 update (valkey-io#3697) added DICT_INCLUDE_DIR=../../src/ to
the build flags. This excludes libvalkey's dict.c from the archive,
making the build depend on valkey's dictCreate being linked first.

However, the -I flag ordering (-I../../src/ from SDS_INCLUDE_DIR comes
before -Isrc) already causes libvalkey's source files to compile against
valkey's dict.h. So DICT_INCLUDE_DIR is redundant. Removing it lets
libvalkey's dict.c remain in the archive (harmlessly, since the linker
never pulls it), while the compilation still uses valkey's dict.h.

Without this fix, sentinel crashes immediately on startup:
  crashed by signal: 11, si_code: 1
  Accessing address: 0x90
in sentinelReconnectInstance -> valkeyAsyncConnectBind -> dictCreate.

This matches what unstable does (no DICT_INCLUDE_DIR).

Signed-off-by: Madelyn Olson <madelyneolson@gmail.com>

Reverts the libvalkey portion of #3697 (0.5.0 update).

The 0.5.0 update introduced a `DICT_INCLUDE_DIR` feature whose
implementation is broken: `#include "dict.h"` in `async.c` and
`cluster.c` resolves to libvalkey's local `dict.h` (5-field `dictType`)
instead of valkey's (9-field `dictType`), causing a struct layout
mismatch with the linked `dictCreate`. This crashes every sentinel
instance on startup.

On unstable this works by coincidence because `dict` is typedef'd to
`hashtable` and the memory layout happens to have zeros at the critical
offset. On 9.1 with the traditional dict implementation, it reads
garbage and crashes.

The fix should be done upstream in libvalkey (the `DICT_INCLUDE_DIR`
feature needs to use `<dict.h>` instead of `"dict.h"`). Once that's
fixed upstream, we can re-update.

**Crash signature:**
```
signal 11, accessing address 0x90
sentinelReconnectInstance -> valkeyAsyncConnectBind -> dictCreate
```

Signed-off-by: Madelyn Olson <madelyneolson@gmail.com>