DOCS-1465: Document that wtimeout=0 waits indefinitely for GLE

source/core/write-concern.txt

@@ -154,8 +154,9 @@ If you specify a ``w`` value greater than the number of members that
 hold a copy of the data (i.e., greater than the number of
 non-:term:`arbiter` members), the operation blocks until those members
 become available. This can cause the operation to block forever. To
-specify a timeout threshold for the :dbcommand:`getLastError` operation,
-use the ``wtimeout`` argument.
+specify a timeout threshold in milliseconds for the :dbcommand:`getLastError` operation,
+use the ``wtimeout`` argument. A ``wtimeout`` value of ``0``
+means the operation will never time out.
 
 See :ref:`getLastError Examples <gle-examples>` for example
 invocations.

source/reference/command/getLastError.txt

@@ -62,3 +62,6 @@ that resembles the following:
 .. code-block:: javascript
 
    db.runCommand( { getLastError: 1, w: 2, wtimeout:5000 } )
+
+When ``wtimeout`` is ``0``, :method:`~db.runCommand()` waits forever.
+

source/reference/connection-string.txt

@@ -231,7 +231,8 @@ the: :doc:`/core/write-operations`:
 .. data:: uri.wtimeoutMS
 
    The time in milliseconds to wait for replication to succeed, as
-   specified in the :data:`~uri.w` option, before timing out.
+   specified in the :data:`~uri.w` option, before timing out. When ``wtimeoutMS`` is ``0``,
+   write operations will never time out.
 
 .. data:: uri.journal
 

source/reference/write-concern.txt

@@ -118,7 +118,7 @@ configure write concern requirements:
 
 :dbcommand:`getLastError` also supports a ``wtimeout`` setting which
 allows clients to specify a timeout for the write concern: if you
-don't specify ``wtimeout`` and the :program:`mongod` cannot fulfill
+don't specify ``wtimeout``, or if you give it a value of ``0``, and the :program:`mongod` cannot fulfill
 the write concern the :dbcommand:`getLastError` will block,
 potentially forever.