Change default value for `KeyspaceEventMessageListener` on keyspace event notifications

[jxblum]

The default value in Spring Data Redis for notify-keyspace-events is set to EA. Therefore, when a user declares and registers a bean of type KeyExpirationEventMessageListener (which extends KeyspaceEventMessageListener) in the Spring ApplicationContext, Spring Data Redis will send a config set notify-keyspace-events EA command to the Redis server on initialization (and then init()).

While this may be "convenient" during development, it is NOT (ever) appropriate for production deployments, and can lead to confusing behavior exactly like this.

With a combination of Lettuce attempting to reconnect (Jedis will not automatically reconnect) and the fact that Redis does not retain configuration changes between restarts (i.e. non-persistent config when changed at runtime; even when applied using the redis-cli), then this situation, such as in Issue #2654, can occur.

NOTE: It is not uncommon for data stores to retain (persist) dynamic configuration changes between sessions.

Therefore, it is recommend the default value in Spring Data Redis be changed to empty, precisely how the Redis server (in redis.conf from a clean install) defines this setting, itself.

If users change the default (e.g. to EA, or otherwise), then they have chosen to "opt-in" and are therefore responsible for the change, such as when the Redis server needs to be restarted.

As explained in Issue #2654, the appropriate location to declare "infrastructure-related" configuration settings to the Redis server is in the redis.conf file, where it belongs! Additionally, users must ensure any custom (modified) configuration file is then passed to and recognized by the Redis server on start.

TIP: On a positive note, the customized/modified redis.conf used to change the default behavior of the Redis server can be checked into version control the same as the application source code that requires the Redis server to behave in a custom way.

In conclusion, the framework, or any library for that matter, should never be making "infrastructure" decisions for users.