Fixed #36744 -- Improved scrypt password hasher docs.

- Corrected work_factor description and its requirements.
- Added block_size description.
- Changed parallelism description to mention computations, rather than
  threads (currently it's not multithreaded.)
- For all of the above, added standard scrypt terminology (N, r, p).
- Mentioned that in multithreaded implementations, parallelism also
  influences the memory requirements.

docs/topics/auth/passwords.txt

@@ -285,15 +285,18 @@ follows:
 
 scrypt_ has the following attributes that can be customized:
 
-#. ``work_factor`` controls the number of iterations within the hash.
-#. ``block_size``
-#. ``parallelism`` controls how many threads will run in parallel.
+#. ``work_factor`` controls the number of iterations within the hash and the
+   size of memory for computation (*N*). It must be a power of 2.
+#. ``block_size`` controls the internal block size (*r*), tuning the algorithm
+   to memory latency.
+#. ``parallelism`` controls how many independent computations may run in
+   parallel (*p*).
 #. ``maxmem`` limits the maximum size of memory that can be used during the
    computation of the hash. Defaults to ``0``, which means the default
    limitation from the OpenSSL library.
 
 We've chosen reasonable defaults, but you may wish to tune it up or down,
-depending on your security needs and available processing power.
+depending on your security needs and available processing power and memory.
 
 .. admonition:: Estimating memory usage
 
@@ -304,6 +307,9 @@ depending on your security needs and available processing power.
     so you may need to tweak ``maxmem`` when changing the ``work_factor`` or
     ``block_size`` values.
 
+    If the underlying implementation of scrypt_ is fully multithreaded, the
+    memory requirement is multiplied by the ``parallelism`` value.
+
 .. _password-upgrades:
 
 Password upgrading