[NEW] Add new keywords for ACL selectors to inherit the commands and key patterns from root selector

The problem/use-case that the feature addresses

There are cases that most of a selector's key patterns are same to the root selector, so there are many duplicated key patterns between selectors in ACL rules. This feature introduces new keywords to simplify the ACL rule.

For example, if we want to give a user all write permissions on k1 and k2, and give all write permission except del on k3, we can use the following ACL rule:

acl setuser u on >pass +@write ~k1 ~k2 (+@write -del ~k1 ~k2 ~k3)

Notice in the selector we have to set (~k1 ~k2 ~k3), because if we only set (~k3), the user will not have permission to execute a write command(not del) on both k1, k2 and k3(for example, it have no permission to execute mset k1 v1 k2 v2 k3 v3).

In this case we have to copy all the patterns from the root selector, and if the key patterns in the root selector are more complex, then it will also be more complicated to write the ACL rules.

Description of the feature

This feature introduces a new keyword named rootkeys which is used in a selector to indicate that this selector has inherited all the key patterns from the root selector. For example, the earlier ACL rule can be written as:

acl setuser u on >pass +@write ~k1 ~k2 (+@write -del rootkeys ~k3)

The rootkeys keyword can only be used inside a selector.

This feature also introduces another keyword +@root. It is used in a selector to indicate that this selector has inherited all the permissions from the root selector, so the earlier ACL rule can be written as:

acl setuser u on >pass +@write ~k1 ~k2 (+@root -del rootkeys ~k3)

The +@root can only be used inside a selector, and is also restricted at the beginning of a selector.

Another thing that needs to mention is that with these 2 keywords a selector can only inherit the permissions and key patterns from the root selector at the time the selector is parsed, later changes about the root selector do not affect the selectors.

So we can play some tricks for example:

acl setuser u on >pass +@all ~k1 (+@root rootkeys) -del ~k2 (+@root rootkeys) -@write ~k3 (+@root rootkeys) -@all resetkeys

This ACL rule does the following things:

1. When parsing at acl setuser u on >pass +@all ~k1 (+@root rootkeys), we create a selector that gives all permissions on k1

2. When we reach the second selector, acl setuser u on >pass +@all ~k1 (+@root rootkeys) -del ~k2 (+@root rootkeys), the root selector had changed, but the earlier selector stays the same, and, we create another new selector that gives all permissions except del on k1 and k2

3. When we reach the last selector, we create a new selector that gives +@all -del -@write permissions on k1, k2, and k3.

4. Finally, we use -@all resetkeys to clear and reset the root selector, and we are free to set the root selector to anything we want in the future without changing the 3 selectors we created

Without these new keywords, we can use separate ACL rules to achieve the same result, but that's far more complicated.

Alternatives you've considered

I read this redis doc and it seems there is no similar feature to achieve this right now

Additional information

Demo of this feature may looks like these:

Start by locating Redis's ACL selector parsing and the tests that cover selector permissions and key patterns; no specific files or tests are named in the issue. The work is complete when rootkeys and +@root are accepted only in their stated contexts, inherit permissions and patterns at parse time, and preserve earlier selectors after later root-selector changes.