Checks flyway deadlock risk for new schema chagnes (#2078)

* Checks flyway deadlock risk for new schema chagnes

db/README.md

@@ -56,11 +56,23 @@ following steps:
     table statements can be used as is, whereas alter table statements should be
     written to change any existing tables.
  
-    Note that each incremental file MUST be limited to changes to a single
-    table (otherwise it may hit deadlock when applying on sandbox/production
-    where it'll be competing against live traffic that may also be locking said
-    tables but in a different order). It's OK to include these separate Flyway
-    scripts in a single PR.
+    If an incremental file changes more than one schema element (table, index,
+    or sequence), it MAY hit deadlocks when applied on sandbox/production where
+    it'll be competing against live traffic that may also be locking said
+    elements but in a different order. The `FlywayDeadlockTest` checks for this
+    risk for every new incremental file to be merged. Simply put, the test
+    treats any of the following as a changed element, and raises an error if a
+    new file has more than one changed elements:
+
+    *   A schema element (table, index, or sequence) being altered.
+    *   The table on which an index is created without the `concurrently`
+        modifier. Please refer to
+        <a href="./src/test/java/google/registry/sql/flyway/FlywayDeadlockTest.java">
+        the test class's javadoc</a> for more information.
+
+    Any file failing this test should be split up according to the error
+    message. It's OK to include these separate Flyway scripts in a single PR.
+
 
     This script should be stored in a new file in the
     `db/src/main/resources/sql/flyway` folder using the naming pattern