Rewrite disaster recovery based on recreate and status check (#1890) (#…

…2027)

This PR rewrites the disaster recovery docs based on the new recreate
and status check procedures.

With regards to the functional changes there are three major things to
note.
1. The recovery of the system database is the same as before, even
though the way we check if the system db is write available or not has
changed.
2. The step which removes lost servers now also includes recreating some
databases. It was decided this mixing of recovering servers and
databases is necessary to get recreate into the guide in the best way we
could see.
3. Previously it was not clear how to handle quarantined databases, even
though the guide mentioned them in the intro. Now, it is more explicitly
discussed how they are supposed to be handles during disaster recovery.


In the past, we have also gotten feedback that the disaster recovery
docs are hard to follow. Therefore, this PR also includes refactoring
which introduces a new guide structure. This new structure provides more
explanations of why we are asking the user to do a certain thing.

---------

Co-authored-by: Anna Sjerling <[email protected]>

modules/ROOT/pages/clustering/databases.adoc

@@ -268,8 +268,8 @@ Neo4j 5.24 introduces the xref:procedures.adoc#procedure_dbms_cluster_recreateDa
 * To change the database store to a specified backup, while keeping all the associated privileges for the database.
 
 * To make your database write-available again after it has been lost (for example, due to a disaster).
-// See xref:clustering/disaster-recovery.adoc[] for more information.
-
+See xref:clustering/disaster-recovery.adoc[Disaster recovery] for more information.
+ 
 [CAUTION]
 ====
 The recreate procedure works only for real user databases and not for composite databases, or the `system` database.