add the diagrams and some editorial updates

Author: renetapopova

modules/ROOT/images/scalability/cluster.png

@@ -60,7 +60,7 @@ More fault-tolerant, eliminates single points of failure. +
 Every update request is handled by a single cluster member, which eliminates single points of failure.
 Each part of the database on a single cluster member is called a *shard*.
 
-image::horizontal-scaling-strategies.png[title="An example of horizontal scaling strategies.", role="middle"]
+image::scalability/horizontal-scaling-strategies.svg[title="Example of a sharing approach where all the servers share the storage vs a shared-nothing approach (e.g., property sharding).", role="middle"]
 
 == What is graph database scalability?
 

modules/ROOT/images/scalability/horizontal-scaling-strategies.svg

@@ -130,7 +130,7 @@ Failure to meet this requirement will make a given replica of a property shard u
 If a property shard replica does fall behind the transaction log range available on the graph shard, you can recover it by:
 
 . Connecting to the `system` database on the server hosting the affected replica using the _bolt://_ scheme.
-. Quarantining the replica using xref:procedures.adoc#procedure_dbms_quarantineDatabase[`dbms.quarantineDatabase()`].
+//. Quarantining the replica using xref:procedures.adoc#procedure_dbms_quarantineDatabase[`dbms.quarantineDatabase()`].
 . Unquarantining the replica using xref:procedures.adoc#procedure_dbms_unquarantineDatabase[`dbms.unquarantineDatabase()`] with the `replaceStateReplaceStore` option.
 This will force the replica to copy the database store files from another replica of the property shard.