Implement notifications, pushers and key backup

[Fizzadar]

No description provided.

[indent]

PR Summary

Adds three Matrix feature areas to the babbleserv (FoundationDB) homeserver: per-event notification counts with thread support, push rules + evaluation + pushers + push-gateway sending, and key backup APIs. Also removes the per-database Enabled config flags (Rooms/Accounts/Transient are now always initialized; deployment is gated by top-level RoutesEnabled/WorkersEnabled), refactors the notifier to deliver the full Change object to subscribers, and bumps Go to 1.27.

• Notification counts stored as msgpack deltas per event version, summed on /sync (with per-thread counts via MSC3773), cleared on read receipts, and compacted by a background iterator; room member counts are now maintained incrementally to feed push-rule conditions.
• Push rules stored in a new accounts directory, evaluated during event send, and delivered to clients as m.push_rules account data on sync; pushers stored per user with new /pushers endpoints.
• New PushNotificationIterator sends pushes to each user's pushers for notifying events; CompactNotificationIterator trims old notification entries.
• Key backup versions/keys implemented with count + etag metadata and the full /room_keys/* endpoint set.

Issues

All clear! No issues remaining. 🎉

8 issues already resolved

• The push-gateway counts.unread is set to notifCount + highlightCount, but highlighted events already contribute to notifCount, so the push badge is inflated by the number of highlighted messages. (fixed by commit 116c03e)
• getThreadRootID walks m.thread relations with no cycle/depth guard, so a stored self-referencing or cyclic thread relation (reachable via federation) loops forever inside the event-send write transaction, wedging the room and burning CPU. (fixed by commit 116c03e)
• Once a room crosses MaxNotificationsPerUserRoom, roomIDToCount is never reset to 0, so compaction runs on every subsequent event in that room, and roomIDToCount/roomIDToCancel entries are never removed. (fixed by commit 03c1d1e)
• Pushers are keyed by (userID, pushKey), but the Matrix spec identifies a pusher by the (app_id, pushkey) pair, so two pushers sharing a pushkey with different app_ids collide and overwrite each other. (fixed by commit 116c03e)
• PutPushRule ignores the before/after query params and the storage keys rules by ruleId, so user rules are returned in lexical order appended after defaults and cannot be reordered, producing wrong push-rule evaluation order. (fixed by commit f5c2dee)
• DELETE of a predefined .m.rule.* rule with no user override returns 200, bumps the push-rules version, and emits a spurious m.push_rules sync, while the rule remains present; the spec requires 404 and server defaults cannot be deleted. (fixed by commit f5c2dee)
• PutPushRule does not reject ruleIds starting with '.' (reserved for server defaults) or containing '/' or '', so a client can shadow a predefined rule and cause GET to report it with default:false. (fixed by commit f5c2dee)
• Errors from sendPushNotificationsForEvents are logged but ignored, and the stored iterator position is advanced past the batch anyway, so a transient DB error permanently skips push notifications for those events. (fixed by commit 116c03e)

CI Checks

All CI checks passed on ea91220.