Rewrite lazyfree docs in valkey.conf to reflect that lazy is now default (valkey-io#983)

Before this doc update, the comments in valkey.conf said that DEL is a
blocking command, and even refered to other synchronous freeing as "in a
blocking way, like if DEL was called". This has now become confusing and
incorrect, since DEL is now non-blocking by default.

The comments also mentioned too much about the "old default" and only
later explain that the "new default" is non-blocking.

This doc update focuses on the current default and expresses it like
"Starting from Valkey 8.0, lazy freeing is enabled by default", rather
than using words like old and new.

This is a follow-up to valkey-io#913.

---------

Signed-off-by: Viktor Söderqvist <[email protected]>
Signed-off-by: Ping Xie <[email protected]>

Author: zuiderkwast

valkey.conf

@@ -1248,24 +1248,25 @@ acllog-max-len 128
 
 ############################# LAZY FREEING ####################################
 
-# The server has two primitives to delete keys. One is called DEL and is a blocking
-# deletion of the object. It means that the server stops processing new commands
+# When keys are deleted, the served has historically freed their memory using
+# blocking operations. It means that the server stopped processing new commands
 # in order to reclaim all the memory associated with an object in a synchronous
 # way. If the key deleted is associated with a small object, the time needed
 # in order to execute the DEL command is very small and comparable to most other
 # O(1) or O(log_N) commands in the server. However if the key is associated with an
 # aggregated value containing millions of elements, the server can block for
 # a long time (even seconds) in order to complete the operation.
 #
-# For the above reasons the server also offers non blocking deletion primitives
-# such as UNLINK (non blocking DEL) and the ASYNC option of FLUSHALL and
-# FLUSHDB commands, in order to reclaim memory in background. Those commands
-# are executed in constant time. Another thread will incrementally free the
-# object in the background as fast as possible.
+# For the above reasons, lazy freeing (or asynchronous freeing), has been
+# introduced. With lazy freeing, keys are deleted in constant time. Another
+# thread will incrementally free the object in the background as fast as
+# possible.
 #
-# DEL, UNLINK and ASYNC option of FLUSHALL and FLUSHDB are user-controlled.
-# It's up to the design of the application to understand when it is a good
-# idea to use one or the other. However the server sometimes has to
+# Starting from Valkey 8.0, lazy freeing is enabled by default. It is possible
+# to retain the synchronous freeing behaviour by setting the lazyfree related
+# configuration directives to 'no'.
+
+# Commands like DEL, FLUSHALL and FLUSHDB delete keys, but the server can also
 # delete keys or flush the whole database as a side effect of other operations.
 # Specifically the server deletes objects independently of a user call in the
 # following scenarios:
@@ -1285,19 +1286,18 @@ acllog-max-len 128
 #    its primary, the content of the whole database is removed in order to
 #    load the RDB file just transferred.
 #
-# In all the above cases the old default is to delete objects in a blocking way,
-# like if DEL was called. Now the new default is release memory in a non-blocking
-# way like if UNLINK was called.
+# In all the above cases, the default is to release memory in a non-blocking
+# way.
 
 lazyfree-lazy-eviction yes
 lazyfree-lazy-expire yes
 lazyfree-lazy-server-del yes
 replica-lazy-flush yes
 
-# It is also possible, for the case when to replace the user code DEL calls
-# with UNLINK calls is not easy, to modify the default behavior of the DEL
-# command to act exactly like UNLINK, using the following configuration
-# directive:
+# For keys deleted using the DEL command, lazy freeing is controlled by the
+# configuration directive 'lazyfree-lazy-user-del'. The default is 'yes'. The
+# UNLINK command is identical to the DEL command, except that UNLINK always
+# frees the memory lazily, regardless of this configuration directive:
 
 lazyfree-lazy-user-del yes