Rewrite lazyfree docs in valkey.conf to reflect that lazy is now default (#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 #913.

---------

Signed-off-by: Viktor Söderqvist <viktor.soderqvist@est.tech>
Signed-off-by: Ping Xie <pingxie@google.com>

valkey.conf

@@ -1248,8 +1248,8 @@ acllog-max-len 128
 
 ############################# LAZY FREEING ####################################
 
-# The server has two primitives to delete keys. One is called DEL and is a blocking
+# When keys are deleted, the served has historically freed their memory using
-# deletion of the object. It means that the server stops processing new commands
+# 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
@@ -1257,15 +1257,16 @@ acllog-max-len 128
 # 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
+# For the above reasons, lazy freeing (or asynchronous freeing), has been
-# such as UNLINK (non blocking DEL) and the ASYNC option of FLUSHALL and
+# introduced. With lazy freeing, keys are deleted in constant time. Another
-# FLUSHDB commands, in order to reclaim memory in background. Those commands
+# thread will incrementally free the object in the background as fast as
-# are executed in constant time. Another thread will incrementally free the
+# possible.
-# object in the background as fast as possible.
 #
-# DEL, UNLINK and ASYNC option of FLUSHALL and FLUSHDB are user-controlled.
+# Starting from Valkey 8.0, lazy freeing is enabled by default. It is possible
-# It's up to the design of the application to understand when it is a good
+# to retain the synchronous freeing behaviour by setting the lazyfree related
-# idea to use one or the other. However the server sometimes has to
+# 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,
+# In all the above cases, the default is to release memory in a non-blocking
-# like if DEL was called. Now the new default is release memory in a non-blocking
+# way.
-# way like if UNLINK was called.
 
 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
+# For keys deleted using the DEL command, lazy freeing is controlled by the
-# with UNLINK calls is not easy, to modify the default behavior of the DEL
+# configuration directive 'lazyfree-lazy-user-del'. The default is 'yes'. The
-# command to act exactly like UNLINK, using the following configuration
+# UNLINK command is identical to the DEL command, except that UNLINK always
-# directive:
+# frees the memory lazily, regardless of this configuration directive:
 
 lazyfree-lazy-user-del yes