Fix missing deletion bug

Old SOGS stores a deleted message ids table with its own separate ids
that track when messages are deleted.  When Session clients send a
request to fetch room updates, they include a parameter "give me all
deletions since deletion id X".

New SOGS just stores an update counter in the room itself (because this
will also be used for tracking/fetching edits, so we need more than just
deletion tracking), which gets incremented on every message deletion or
message update.

The import set this update counter to the number of deletions that it
imported -- but old SOGS had a bug where it would insert deletion rows
multiple times (in one case 24 times), driving up the deletion id; the
sogs import just skips over the duplicates when importing.

But that caused issues because, e.g. for the Crypto room, it had a
message deletion id of 5207, but only had 5108 unique deletions: so the
imported crypto room got its update counter set to 5108.  Thus new
deletions were incrementing that update counter, as they are supposed
to, but your client was still saying "give me deletions since 5207" so
it never fetched the first 101 deletions.

When I started testing things this morning, it was working perfectly
everywhere I tested it, which was extra frustrating: turns out that's
because because we've now had enough deletions to bump those update
counters to be higher than the imported counter.

This fixes the issue by using the max deletion id as the room.updates
counter if greater than the number of room updates.

Author: jagerman

sogs/migrate01x.py

@@ -233,7 +233,17 @@ def migrate01x(conn):
                     )
                 )
 
-                cur.execute("UPDATE rooms SET updates = ? WHERE id = ?", (updated, room_id))
+                # Old SOGS has a bug where it inserts duplicate deletion tombstones (see above), but
+                # this means that our updated count might not be large enough for existing Session
+                # clients to not break: they will be fetching deletion ids > X, but if we have 100
+                # duplicates, the room's update counter would be X-100 and so existing clients
+                # wouldn't actually fetch any new deletions until the counter catches up.  Fix that
+                # up by incrementing the updates counter if necessary.
+                top_del_id = rconn.execute("SELECT MAX(id) FROM deleted_messages").fetchone()[0]
+
+                cur.execute(
+                    "UPDATE rooms SET updates = ? WHERE id = ?", (max(updated, top_del_id), room_id)
+                )
 
                 # If we have to offset rowids then make sure the hack table exists and insert our
                 # hack.