Add Support for redis 7 commands

[chayim]

As part of the upcoming Redis 7 release, at least the following commands should be implemented. As part of this tracking, we'll also need to start a redis 7 docker, and integrate it into tox. For commands that will not be implemented in the client - we want to define a function, and raise a NotImplementedError (like others!), ensuring the documentation states that this is the behaviour.

• Add support for LMPOP #1798
• Add support for BLMPOP #1799
• Add support for BZMPOP #1800
• Add support for CLIENT NO-EVICT #1801
• Add support for CLUSTER ADDSLOTSRANGE #1802
• Add support for CLUSTER DELSLOTSRANGE #1803
• Add support for EVAL RO #1804
• Add support for EVALSHA_RO #1805
• Add support for EXPIRETIME #1806
• Add support for PEXPIRETIME #1807
• Add support for SINTERCARD #1808
• Add support for SORT_RO #1809
• Add support for LCS #1810
• Add support for ZINTERCARD #1811
• Add support for ZMPOP #1846
• Add support for PEXPIRE redis-7 options [NX|XX|GT|LT] #1938
• Add support for PEXPIREAT redis-7 options [NX|XX|GT|LT] #1939
• Add support for PUBSUB SHARDCHANNELS #1940
• Add support for SPUBLISH #1941
• Add support for SSUBSCRIBE #1942
• Add support for SUNSUBSCRIBE #1943
• Add support for CLUSTER LINKS #1945
• Add support for COMMAND DOCS #1946
• Add support for COMMAND GETKEYSANDFLAGS #1947
• Add support for COMMAND LIST #1948
• Add support for EXPIRE redis-7 options [NX|XX|GT|LT] #1949
• Add support for EXPIREAT redis-7 [NX|XX|GT|LT] #1950
• Add support for EXPIRETIME #1951
• Add support for FCALL #1952
• Add support for FCALL_RO #1953
• Add support for FUNCTION DELETE #1954
• Add support for FUNCTION DUMP #1955
• Add support for FUNCTION FLUSH #1956
• Add support for FUNCTION KILL #1957
• Add support for FUNCTION LIST #1958
• Add support for FUNCTION LOAD #1959
• Add support for FUNCTION RESTORE #1960
• Add support for missing command BITCOUNT - [BYTE|BIT] field #1965
• Add support for missing command BITPOS - [BYTE|BIT] field #1967
• Add support for CLUSTER SHARDS #2120
• CONFIG GET - add the ability to pass multiple pattern parameters in one call #2121
• CONFIG SET - add the ability to set multiple parameters in one call #2122
• INFO - add support for taking multiple section arguments #2123
• Add support for LATENCY HISTOGRAM #2124
• Add support for MODULE LOADEX #2125
• SHUTDOWN - add support for the new NOW, FORCE and ABORT modifiers #2126
• XADD - add support for the <ms>-* explicit ID form #2127
• XGROUP CREATE - add support for ENTRIESREAD field #2128
• XGROUP SETID - add support for ENTRIESREAD field #2129
• XSETID - add support for ENTRIESADDED and MAXDELETEDID fields #2130
• ACL GETUSER - add selectors and change the format of key and channel patterns from a list to their rule representation #2131
• ACL SETUSER - add selectors and key based permissions #2132
• CLUSTER SLOTS - add additional networking metadata field #2133
• XAUTOCLAIM - add an element to the reply array, containing deleted entries the command cleared from the PEL #2134
• XINFO GROUPS - add the entries-read and lag fields #2135
• XINFO STREAM - add the max-deleted-entry-id, entries-added, recorded-first-entry-id, entries-read and lag fields #2136

[madolson]

There will be new publish commands, per (https://github.com/redis/redis/pull/8621/files). Mentioning this because the logic for pubsub will also be changed a little bit for cluster mode. There is logic that sets the "first" key from a command ,

redis-py/redis/commands/parser.py

Line 112 in b94e230

elif command in ["SUBSCRIBE", "PSUBSCRIBE", "UNSUBSCRIBE", "PUNSUBSCRIBE"]:

, that explicitly looks for a pubsub flag + the name, this will cause the new commands to return NULL.

[Andrew-Chen-Wang]

Is it possible for there to be a change in ownership of aioredis to RedisLab or for Redis employees to make parallel PRs to aioredis? All these commands only need a simple async/await combination. Aioredis is vital to the asyncio Python community like FastAPI and Django channels, and I can't keep up with a paid staff, especially during school.

[madolson]

@Andrew-Chen-Wang I'm not from Redis Ltd, but perhaps it might make sense to merge in the async functionality into the main repo instead of maintaining a fork? Would that be a lot of work?