Document the new default value for 'replication_sync_timeout' (#3507)

Author: andreyaksenov

doc/reference/configuration/cfg_replication.rst

@@ -346,6 +346,11 @@
     | Environment variable: TT_REPLICATION_SYNC_TIMEOUT
     | Dynamic: **yes**
 
+    .. NOTE::
+
+        The default ``replication_sync_timeout`` value is going to be changed in future versions from ``300`` to ``0``.
+        You can learn the reasoning behind this decision from the :ref:`Default value for replication_sync_timeout <compat-option-replication-timeout>` topic, which also describes how to try the new behavior in the current version.
+
 .. _cfg_replication-replication_timeout:
 
 .. confval:: replication_timeout

doc/reference/reference_lua/compat/box_cfg_replication_sync_timeout.rst

@@ -3,7 +3,7 @@
 Default value for replication_sync_timeout
 ==========================================
 
-Having a non-zero ``replication_sync_timeout`` gives a user the false assumption that the ``box.cfg{replication = ...}`` call returns only when the configured node is synced with all the other nodes.
+Having a non-zero :ref:`replication_sync_timeout <cfg_replication-replication_sync_timeout>` gives a user the false assumption that the ``box.cfg{replication = ...}`` call returns only when the configured node is synced with all the other nodes.
 This is mostly true for the big ``replication_sync_timeout`` values, but it is not 100% guaranteed.
 In other words, a user still has to check if the node is synced, or the sync just timed out.
 Besides, while ``replication_sync_timeout`` is ticking, you cannot reconfigure ``box`` with another ``box.cfg`` call, which hardens reconfiguration.
@@ -13,7 +13,7 @@ It is decided to set the ``replication_sync_timeout`` to zero by default.
 Old and new behavior
 --------------------
 
-The ``compat`` module allows you chose between
+The ``compat`` module allows you to choose between
 
 *   the old behavior: ``box.cfg.replication_sync_timeout`` is 300 seconds by default
 
@@ -59,8 +59,8 @@ Known compatibility issues
 
 At this point, no incompatible modules are known.
 
-Detecting issues in you codebase
---------------------------------
+Detecting issues in your codebase
+---------------------------------
 
 We expect issues with a user assuming that the node is not in the orphan state (``box.info.status ~= "orphan"``) after the ``box.cfg{replication=...}`` call returns.
 This is not true with the new behaviour. To simulate the old behavior, one may add a ``box.ctl.wait_rw()`` call after the ``box.cfg{}`` call.

doc/reference/reference_lua/compat/fiber_channel_close_mode.rst

@@ -99,8 +99,8 @@ Known compatibility issues
 
 At this point, no incompatible modules are known.
 
-Detecting issues in you codebase
---------------------------------
+Detecting issues in your codebase
+---------------------------------
 
 The new behavior is mostly backward compatible.
 The only known problem that can appear is when the code relies on channel being entirely closed after ``ch:close()`` and ``ch:get()`` returning ``nil``.

doc/reference/reference_lua/compat/fiber_slice_default.rst

@@ -23,8 +23,8 @@ Known compatibility issues
 
 At this point, no incompatible modules are known.
 
-Detecting issues in you codebase
---------------------------------
+Detecting issues in your codebase
+---------------------------------
 
 If you see a warning like this in the log:
 

doc/reference/reference_lua/compat/json_escape_forward_slash.rst

@@ -39,8 +39,8 @@ Known compatibility issues
 
 At this point, no incompatible modules are known.
 
-Detecting issues in you codebase
---------------------------------
+Detecting issues in your codebase
+---------------------------------
 
 Both encoding styles are correct from the JSON standard standpoint, but if your module relies on encodings results bytewise, it may break with this change.
 Be cautious if you do the following:

doc/reference/reference_lua/compat/sql_seq_scan_default.rst

@@ -88,8 +88,8 @@ Known compatibility issues
 
 At this point, no incompatible modules are known.
 
-Detecting issues in you codebase
---------------------------------
+Detecting issues in your codebase
+---------------------------------
 
 We expect most SELECTs that do not use indexes to fail after the ``sql_seq_scan`` session setting is set to false.
 The best way to avoid this is to refactor the query to use indexes.

doc/reference/reference_lua/compat/yaml_pretty_multiline.rst

@@ -47,8 +47,8 @@ Known compatibility issues
 
 At this point, no incompatible modules are known.
 
-Detecting issues in you codebase
---------------------------------
+Detecting issues in your codebase
+---------------------------------
 
 Both encoding styles are correct from the YAML standard standpoint, but if your module relies on encodings results bytewise, it may break with this change.
 Be cautious if you do the following: