The problem/use-case that the feature addresses

We've had several folks at AWS request improvements to auditing for compliance and/or security purposes. They are mainly interested in the following cases in the given order:

1. Which user accessed the database at which time with which permissions.
2. What changes occurred to data, and from which user and IP was the data modified.
3. Who accessed what data at what point in time.
4. Full auditing of all commands and when they occurred.

Depending on which user we talked to, different folks had different opinions on the requirements.

Description of the feature

Native Redis support for recording the mentioned data, with configuration options to determine what level is being audited. I think 1) is not that hard to sell as an idea. The remaining items are basically just high volume writes to disk in some format.

I also kind of want to revisit the conversation of implementing these types of features as modules, specifically one that is included by default in our docker container and rpm (and maybe stack?). That way they are more or less included by default, but we could potentially better scale the team by having it in a separate github package. (Could also be a "first" party module").

Alternatives you've considered

1. I believe this could be technically implemented as a module. Filtering allows us to see each command. Something better might be the interceptors that were discussed in Support module API for global block list #10819.
2. One user asked about instrumenting everything with a FUNCTION. They wanted to execute a function like FCALL EXEC 0 SET FOO BAR, which took the arguments of the argument and passed them through. This is bad for a couple of reasons, namely it doesn't declare keys.
3. Monitor solves some of these problems, but it also can break if the client is disconnected.