As per the docs, unstableResp3 commands should throw
when client is created with { RESP: 3, unstableResp3: false|undefined }

fixes #2989

refactored bitop tests, covered all operations

updated default docker version on all packages

* wip

* improve the vadd api

* resp3 tests

* fix some tests

* extract json helper functions in client package

* use transformJsonReply

* remove the CACHEABLE flag for all vector set commands

currently, client side caching is not supported
for vector set commands by the server

* properly transform vinfo result

* add resp3 test for vlinks

* add more tests for vrandmember

* fix vrem return types

* fix vsetattr return type

* fix vsim_withscores

* implement vlinks_withscores

* set minimum docker image version to 8

* align return types

* add RAW variant for VEMB -> VEMB_RAW

* use the new parseCommand api

Also, touch the tests for spop and spopcount
to use the new parseCommand API

fixes #3004

#3005)

`createSentinel` takes RESP as an option, but does not propagate down
to the actual clients. This creates confusion for the users as they
expect the option to be set to all clients, which is reasonable.

In case of clientSideCaching, this problem manifests as validation failure
because clientSideCaching requires RESP3, but if we dont propagate,
clients start with the default RESP2

fixes #3010

Co-authored-by: Florian Schunk <149071178+florian-schunk@users.noreply.github.com>

main branch is protected and does not allow direct pushes.
the release action needs to push.
branch protection rules can be bypassed for people and apps, but not
github actions.

one of the workarounds is to use a ruleset in which we set a deploy key

see: https://github.com/orgs/community/discussions/25305\#discussioncomment-10728028